`rustup component (add|remove)` should not rely on hardcoded target triples about rustup HOT 9 OPEN

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).

from rustup.

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.

from rustup.