Add `--print=llvm-target-tuple`

[ChrisDenton]

Proposal

Add --print=llvm-target-tuple to print the target tuple that should be passed to clang and other llvm tools.

> rustc --print=llvm-target-tuple --target aarch64-kmc-solid_asp3
aarch64-unknown-none
> rustc --print=llvm-target-tuple --target bpfeb-unknown-none
bpfeb

Motivation

cc-rs needs to figure out how to invoke the C compiler for the current target. To do this it gathers information about the target (such as the target_arch, target_env, etc) and infers the right flags to pass to the C compiler based on that.

Almost all of this information is available via --print=cfg and therefore CARGO_TARGET_CFG_* environment variables in build scripts. However, noticeably missing is the llvm target tuple which is only available via the unstable --print=target-spec-json. This is needed to pass to clang when cross-compiling.

Currently cc-rs is forced to either guess or use a lookup table to discern the current target's llvm tuple. This should ideally be unnecessary because rustc already knows what the llvm target tuple should be (at least with the llvm backend). But there's no (stable) way for cc-rs to get at this information. This is especially important for custom targets where we can only guess at the llvm target tuple.

A useful followup to this MCP would be to add a cargo build script environment variable with this information. But that's a matter for the cargo team.

Alternatives

• The llvm target tuple could be added to --print=cfg but this would be awkward because it would also imply being a #[cfg] conditional compilation value.
• There could be some way for cc-rs (and other crates) to query for the arguments the platform's C compiler(s) need. This would require adding that information to rustc (or a tool shipped with rustc).

Mentors or Reviewers

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:

@rfcbot concern reason-for-concern 
<description of the concern> 

Concerns can be lifted with:

@rfcbot resolve reason-for-concern 

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[Urgau]

Make sense, seconding as unstable. FCP is required for stable option.

@rustbot second

[apiraino]

@rustbot label -final-comment-period +major-change-accepted