Flag to suppress emitting channel info

Background

There are many crates that do version detection in a build script to set cfg to change what they compile, a disappointingly large subset of these also detect the channel and enable unstable features when detecting they might be supported.
There's three general mechanisms used for this "feature detection":

1. Parse rustc -vV and extract the channel name (-nightly) from the version number, assume all unstable features are supported and work as needed.
2. Mechanism one but also parse RUSTFLAGS/CARGO_ENCODED_RUSTFLAGS to detect -Zallow-features and check the actual features are not disabled, assume they will work as needed.
3. Attempt to compile small bits of rust code that try and cover all parts of the unstable feature that will be used to verify it works as needed.

Often mechanism three will be gated behind an initial mechanism one check to avoid the overhead of running all these small tests when it's known they will fail.

Crates doing this cause issues for supposedly-stable transitive dependents when they are compiled with a nightly compiler (e.g. https://github.com/rust-lang/rust/issues/113152). This makes it hard to do things like bisect a range of nightly compiler versions against a locked build to find where some other stable feature regressed.

Today it is possible to force-disable unstable features for crates that use mechanisms two and three: cargo build -Zallow-features=, but for crates using mechanism one you have to do something horrible like wrap rustc in a shell script that hides the channel info.

Proposal

Add a new -Zno-channel-info flag and RUSTC_UNSTABLE_NO_CHANNEL_INFO envvar that supresses the channel-info from being emitted from the version call, when set a nightly-channel compiler built from bf8716f1c would say just rustc 1.77.0 (bf8716f1c 2023-12-24) instead of rustc 1.77.0-nightly (bf8716f1c 2023-12-24).

Mentors or Reviewers

If you have a reviewer or mentor in mind for this work, mention them
here. You can put your own name here if you are planning to mentor the
work.

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.

Comments

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.