Switch to CfgExpr for target testing.

[ehuss]

The code here should not be testing on the target name, but instead should be using the cfg data to test the vendor/os/env fields.

There may be other places in the Cargo codebase that example the target triple that should probably also use cfg testing.

[weihanglo]

I thought it is easy. I was completely wrong 🤯. Found that it is impossible for us to parse <arch>-<vendor>-<os>-<env> correctly unless we rewrite Triple::normalize in LLVM TargetParser. And we do have some funky real world examples, like wasm32-wasi is actually wasm32-unknown-wasi.

Or alternatively, we can check the supported target list in rust-lang/rust in as test cases, and make sure they are all good?

Feel like we probably should just follow what has been done in rust-lang/rust — compare string directly, so no change needed?

[ehuss]

Hm, sorry if my original message wasn't clear (or maybe I'm confused). The intent is that code should be using the cfg data from TargetInfo. I don't think there is a matching function readily available, but it would essentially be something that iterates over the [Cfg] and finds one that says something like "target_env=msvc" or "target_vendor=apple".

I'm not sure if, for performance reasons, that iterating over the list is an issue, or if it would need a more sophisticated data structure or if it should stash the information somewhere so it only iterates once. My instinct is that it should be fine since the list is usually relatively small, but worth checking.

FWIW, I think this is relatively low priority. The current strings are unlikely to have an unexpected collision with another target, and otherwise it is mostly relevant to using target-spec JSON files, which are unstable.