group target modifier options under `-T`

[davidtwco]

Proposal

rust-lang/rfcs#3716 was accepted and introduced the notion of "target modifiers": flags which must be set consistently across the crate graph for compilation to succeed. In the RFC, "target modifiers" wasn't intended to be a concept that got exposed to end users:

We should be careful to not introduce too many concepts that end-users have to learn.

It is intentional that the guide-level section of this RFC does not use the word “target modifier”. The “target modifier” name is not intended to be used outside of the compiler internals and very technical documentation. Compiler errors should not say “error: trying to mix target modifiers” or something like that; rather the error should just say that mixing -Cfoo may cause ABI issues.

For similar reasons, the flag for silencing the error is called -Cunsafe-allow-abi-mismatch with the word “ABI” to avoid having to teach the user about mismatched flags or target modifiers.

Target modifiers obviously behave differently than other flags - requiring that they're set consistently - but there's also additional differences from other flags that I'm planning to introduce:

1. In cfgs for target modifiers rust#152038, I'm proposing to the language team that we automatically create a cfg for each target modifier flag (see that PR for the full rationale).

2. In yet-unopened follow-ups to the build-std RFCs (build-std: always rfcs#3874 and build-std: explicit dependencies rfcs#3875), I'm going to propose a variant of build-std.when that will automatically rebuild the standard library when a target modifier changes (details will be in the RFC that proposes that).

With these efforts building on our existing support for target modifiers, these flags become more and more different from other flags - they all need to be set the same, automatically have cfgs, and automatically trigger rebuilds of the standard library. At that point, it feels like it would make sense to group these flags together under -T (or another letter, I don't mind which), so as to make it clearer when a flag has these behaviours, and when others don't. We don't necessarily need to introduce the "target modifier" terminology specifically, they could still be referred to as "ABI-modifying flags" or something.

In particular, for rust-lang/rust#152038, we need to decide what name cfgs for target modifiers should have - cfg($flag) or cfg(target_modifier($flag)) or something else - and that decision would be influenced by whether we decide to make any distinction between the the target modifier flags and other flags - hence opening this now, before either of the above land.

All current target modifier flags are unstable today and under -Z. Unstable target modifier flags would remain under -Z. Accepting this MCP wouldn't change anything today (because the flags are all unstable), just change how stabilisation will work for a target modifier when we get around to doing that for one of them.

Mentors or Reviewers

Anyone should be able to review this, I'll do all the implementation

Process

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

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, 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 can formally be registered here by adding a comment.

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

Concerns can be lifted with:

@rustbot resolve reason-for-concern

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

cc @rust-lang/compiler

[bushrat011899]

In rust-lang/cargo#16726, I'm requesting a shorthand for the --manifest-path option to either be -m or -M. To avoid confusion, it'd be ideal that there's no clash between the two usages here (even if one is for cargo and the other for rustc). Would it be expected that target modifiers would be used frequently enough by the user that a shorthand like -M would be substantially more useful than a long name like --abi-modifier?

[epage]

I think the use cases for each -m are likely independent enough to not clash or cause confusion.

Also, from reading this, this is less about the compiler adding a short-alias which seems less appropriate in my mind (as those are a shorthand for humans and most compiler features are unlikely set interactively) and more to follow the pattern of -C which basically creates a sub-grammar within the CLI.

[Urgau]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.