Thanks for the feedback, @zackw!
That seems like a good idea, in general. Ignoring for a moment cases that currently use that vendor field to distinguish target variants (e.g. UWP Windows targets), we may want to attempt to deprecate the use of target_vendor for that, and consider introducing a separate mechanism for distinguishing targets that would otherwise have the same architecture and os. We have https://github.com/rust-lang/rfcs/pull/2992/ , which defines target_abi, such that a -linux-gnueabi target has target_env="gnu" and target_abi="eabi". That might work for UWP targets as well, and potentially other target variants.
@zackw Has there been any discussion elsewhere about conventions regarding things like gnueabi, and splitting that logically into gnu and eabi, with the latter being treated as a separate component with a separate name (e.g. "ABI" rather than "env"/"environment")?
This is exactly the behavior I'd like to see as well, with my lang and cargo hats on. If we map A to B, as far as any Rust code can tell it should always appear that the user passed B.
At least today, we currently have a fairly specific expectation for how we find the target linker, based on the target name; for any given target we'll tend to look for a specific linker by name. (I think there's plenty of room to improve that autodetection.) If we map target A to target B as an alias, and it might potentially be reasonable for a toolchain prefixed with A- to exist rather than B-, does it seem potentially reasonable to assume that either should be acceptable? And in particular, does it seem potentially reasonable to just automatically look for B- as the canonical name and then fall back to looking for the toolchain under an alias prefix, whether the user specified A or B?
I would tend to consider it problematic to have a system with both riscv-linux-ld and riscv-unknown-linux-gnu-ld pointing to programs with non-identical behavior. If we can ignore that case, we could just always look for riscv-unknown-linux-gnu-ld and then riscv-linux-gnu-ld and then riscv-linux-ld, using the first one we find.
Unfortunately, I think that terminology difference may be permanent at this point. This distinction didn't tend to arise within the Rust community, largely I suspect because Rust doesn't have a need to distinguish between toolchains that "target" different systems. One Rust toolchain can target many different systems; you don't need a different Rust toolchain for different targets. As a result, we only ever needed to distinguish "host" (the system you're running on) and "target" (the system you're compiling for), and that terminology has become pervasive throughout the Rust community.