rustup component (add|remove) should not rely on hardcoded target triples

[rami3l]

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue+is%3Aopen%2Cclosed and found no duplicates.
• I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

The direct cause of #3166 is that wasm32-unknown-unknown hasn't been hardcoded into our codebase:

rustup/src/dist/triple.rs

Lines 7 to 37 in a6c9fae

	static LIST_ARCHS: &[&str] = &[
	"i386",
	"i586",
	"i686",
	"x86_64",
	"arm",
	"armv7",
	"armv7s",
	"aarch64",
	"mips",
	"mipsel",
	"mips64",
	"mips64el",
	"powerpc",
	"powerpc64",
	"powerpc64le",
	"riscv64gc",
	"s390x",
	"loongarch64",
	];
	static LIST_OSES: &[&str] = &[
	"pc-windows",
	"unknown-linux",
	"apple-darwin",
	"unknown-netbsd",
	"apple-ios",
	"linux",
	"rumprun-netbsd",
	"unknown-freebsd",
	"unknown-illumos",
	];

[...] we really should not hardcode target triples in our artifact, as the complete list changes quite regularly.

#3601 (comment)

Rustup version

rustup 1.27.0+74 (a6c9fae91 2024-04-21) dirty 1 modification
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.77.2 (25ef9e3d8 2024-04-09)`

[djc]

I think a good approach here would be to add an integration test that can download a recent manifest, parse it, and regenerate a source file that contains current definitions of these (and fails the test if they're outdated).

[rami3l]

I think a good approach here would be to add an integration test that can download a recent manifest, parse it, and regenerate a source file that contains current definitions of these (and fails the test if they're outdated).

@djc The current model of target triples in Rustup requires some non-code knowledge to correctly generate the list:

{ arch: aarch64, os: linux, env: android }
{ arch: aarch64, os: unknown-freebsd}

Looking at the original file, I think a reasonable (but possibly breaking) solution would be parsing the triples as follows:

// for `x-y`
{ arch: x, os: y }

// special case for `x-y-w` where `y` is `none` or `linux`
// e.g. `thumbv4t-none-eabi`, `i686-linux-android`
// (should've been called `x-unknown-y-w`, but alas)
{ arch: x, os: y, env: w }

// for `x-y-z`
{ arch: x, os: y-z }

// for `x-y-z-w`
{ arch: x, os: y-z, env: w }

Then we can get a list of triples by using things like rustc --print target-list (I assume we cannot add/remove a component without even having rustc installed, right?), or by reading the manifest (either at comptime or at runtime) and deduplicating.

[djc]

Yeah, splitting is definitely not completely straightforward, but having an automated test that checks our internal code matches any targets in curent manifests still sounds good.