rustc is unable to build for vendored toolchains by default

[zachreizner]

When rustc is given a target triple to compile for, the behavior, as defined by librustc_back, is to search the list of builtins for an exact match and then to search for the target triple as a file or a json configuration in some search directories. In every case, the target triple is treated as an opaque key to be searched for, contrary to the usual usage of a target triple.

The usual way is to parse the triple into its semantic parts (arch-vendor-system or arch-vendor-kernel-system) and use those parts to build up a target specification (i.e. a struct Target from librustc_back). The consequence of this deviation is that vendored toolchains (toolchains that have something other than a "default" vendor in their triple) won't be recognized by rustc, contrary to the purpose of having a vendor string, which is to allow vendors to use arbitrary toolchains.

The current workaround is either to explicitly add the needed vendor triple to rustc's list of builtins (which requires official support to get into master) or to add a TRIPLE.json to the appropriate path. Granted, these workaround are not onerous, but I believe the "right" way would be to handle the target triples properly by default. I'm putting this issue up for discussion.

[codyps]

Related (but not quite the same): #33147

[metux]

Just curios: which vendor toolchains are you using ?

[zachreizner]

The toolchain's vendor string is "cros" as in "Chrome OS".

[jackh726]

Closing as duplicate of #33147