Rust platform triples should omit and ignore the vendor

[Conan-Kudo]

Currently, rust and cargo use the full platform identity for identifying platforms (<arch>-<vendor>-<os>[-<libc]).

However, the vendor attribute in a platform identity (commonly known as platform triples) is a private attribute intended to indicate variants and configurations. For example, RH/Fedora based distros use <arch>-redhat-linux-gnu for the platform identity, Mageia based ones use <arch>-mageia-linux-gnu, and so on. However, for the purposes of determining platform equivalence, only arch, os, and libc matter.

The tooling should be changed to ignore the vendor attribute and platforms should be similarly altered so that the platform triple should only contain the meaningful attributes.

For example, instead of saying x86_64-unknown-linux-gnu, it would be x86_64-linux-gnu. Alternatively, simply forcing the vendor to always be considered something generic (like pc) would be sufficient.

The vendor attribute is meaningful to humans, but not tools.

[codyps]

Ideally the rust triple wouldn't be examined at all except to locate our target config. That isn't quite the case (especially due to the move towards rustbuild using scanning the target triple a bit more to replace the platform cfg), but it's a decent goal to decouple meaning the triple from it's value (say no to triple parsing).

That said, as soon as we admit that folks may have different configurations that aren't represented by arch-os-libc, they need a way to disambiguate them. Right now, vendor can be used for that purpose, so I don't think we can drop it entirely. That said, it might be possible for the builtin targets to drop their vendors... if we had yet to release them. At the moment, lots of Cargo.toml's, and builds that pass --target, and things that use rustup to download std expect certain targets to have the vendor included, so we can't just remove it without breaking those users.

There might be a place for providing documented rules for how rust target triples should be used/created in the future, though.

[Conan-Kudo]

@jmesmon Maybe vendor aliases could be implemented? For example, if Fedora's rust triple is <arch>-redhat-linux-gnu, the platform configuration could also accept unknown and pc (the generic names) and direct it to the native redhat vendor configuration? That gives you some flexibility you didn't have before, too, as you can identify compatible platforms easily by vendor aliases.

[codyps]

I guess I'd be looking for a real problem that we're solving at that point:

• What specific problem does fix? ie: is there a specific thing that is impossible to avoid without aliases?
• how is such a database of aliases maintained?
• how can we guarantee the aliases are always compatible when rustc doesn't control some of the targets? (or does it control the targets)?

[nagisa]

Duplicate-ish of rust-lang/rust#33147