make zig cc use clang-compatible -target and -mcpu parameters

[eira-fransham]

If you run clang with --target=arm64-unknown-linux-gnu it will understand it to mean the same as arm64-linux-gnu, but with zig cc it returns UnknownOperatingSystem. I wanted to use zig cc in a Rust build script, and this is an issue as Rust only uses 4-part target triples - and so <arch>-unknown-<sys>-<abi> is by far the most common format for targets. While I can work around this in my particular case, I wouldn't expect it to be particularly difficult to implement in Zig and it would make zig cc compatible with clang in more contexts.

[LemonBoy]

I've hit this very same problem today and indeed having to patch the triple every time is annoying.
This said, Zig has no concept of vendors yet so we could:

• Parse and ignore the field,
• Parse the field and relay it to LLVM, Zig is still oblivious to the vendor part,
• Same as above, but only when running zig cc,
• Enhance Zig's triple to include the vendor part too.

[andrewrk]

Currently the -target and -mcpu CLI parameters are parsed according to zig's understanding of these values rather than LLVM's, including in zig cc mode. This is intentional because Zig has a different set of targets than LLVM does, and we do want you to be able to specify operating systems, architectures, and CPU features according to zig's model rather than LLVM's model.

Of course it does have the downside noted by this issue, and when using zig cc the intent is to be clang-compatible. Whether to extend that to -target and -mcpu is the suggestion proposed by this issue.

It's annoying but I think the best solution to the problem is to parse the triple according to LLVM rules, only in zig cc (as @LemonBoy notes in the 3rd option), which involves a more onerous process than simply omitting the vendor, because the CPU model names and CPU features have different syntax (underscore instead of dash, for instance, but also the sets of features are not the same, and some are renamed).

I also haven't marked this as accepted, because, maybe it's better to not be clang-compatible in this one way?

[eira-fransham]

Maybe if there was some standard way to convert between LLVM and Zig triples (and -mcpu arguments) that existed outside of Zig then it wouldn't be so bad? You could then have a really thin script called, like zig clang or whatever, that does the conversion and passes it to zig cc. Seems kinda silly but it could lead to more flexibility in zig cc's argument syntax if you have an entirely separate binary whose only purpose is converting the arguments. So long as some method of conversion is maintained by you or someone else closely connected to the developments in zig cc (so that the conversion doesn't go out of date and/or rely on implementation details or unstable features) then the job of actually writing that binary can go to someone else.

[andrewrk]

Duplicate of #4911