Constrain process required for some user-facing changes to lower support tier targets

[workingjubilee]

Proposal

Currently rust-lang/rust#142321 is open which addresses a long ago request in rust-lang/rust#60617 to expose the ABI version for all powerpc64-anything-using-elf tuples. For PowerPC64, There is an "elfv2" and an "elfv1", and for various reasons it is best if we expose this to Rust programs somehow because there are no fixed attributes that you can actually hang that cfg on. Little endian essentially-always is ELFv2, but that doesn't mean ELFv1 is big-endian, as you can have big-endian ELFv2 targets just fine. And there's obviously no particular reason you can't recompile the GNU code to be ELFv1 or ELFv2, so we can't hinge this all on the libc either (though musl does conveniently only support ELFv2).

...This isn't about fixing that.

It's about how the current way that the Forge section on proposals and stabilization for targets is worded is ambiguous enough that it suggests all user-facing changes to a target we support may require an FCP. We are currently asking for that in another PR, namely rust-lang/rust#139451 which is accordingly taking more time, despite being technically additive (though it is arguably signaling an intent to break certain code on newer platforms). T-compiler FCPs are unfortunately simply notoriously heavyweight for this.

This is a small, additive fix that maybe should be raised for discussion, yes, but probably doesn't need a full FCP. We're not adding something truly new to the compiler, even for this target, we're just making use of what is already available in the language.

I suggest a change to this policy for additive changes that only affect tier 2 targets or below to instead require a lighter amount of process:

• Changes to tier 3 target tuples, even breaking ones, require an r+ at most, because we can simply remove the target with an r+, per the tier 3 target tier policy.
• Additive changes for tier 2 targets in already-covered design spaces, like filling in cfg key-string pairs, requires an MCP at most.
• Note that some cfg keys attend directly on something else, like cfg(target_feature = "..."), and for them the process is unchanged as exposing those implies stabilizing the actual feature.

Mentors or Reviewers

You!

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 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

[davidtwco]

@rustbot second

[apiraino]

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