Require users to confirm they know RUSTC_BOOTSTRAP is unsupported before using it

[jyn514]

Proposal

Currently, the way to break all stability guarantees in the compiler is to set an environment variable: RUSTC_BOOTSTRAP=1. While the release team recommends against this in https://rustc-dev-guide.rust-lang.org/building/bootstrapping.html#complications-of-bootstrapping and various other places, it's easy to see it in forums or discussions and use it without knowing that it's not meant to be used outside of bootstrapping. Additionally, it looks very similar to other benign things, like setting RUST_BACKTRACE=1.

I propose to change the name of RUSTC_BOOTSTRAP to RUSTC_UNSTABLE_ON_STABLE. The intention is not to obfuscate the text, but to make sure the user is making a conscious decision to break stability guarantees instead of copy/pasting from somewhere they saw it online.

For more discussion, see around https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/how.20does.20release.20branching.20work.3F/near/208059954.

Some proposed alternative names:

• RUSTC_FORCE_UNSTABLE
• RUSTC_UNSTABLE
• I_OPT_OUT_OF_RUST_STABILITY_GUARANTEES_AND_CANNOT_COMPLAIN_ABOUT_IT
• RUSTC_BOOTSTRAP="I understand that unstable features are unstable and may break at any time"

Mentors or Reviewers

@joshtriplett for gathering consensus on the change
@Mark-Simulacrum for the implementation (which should be fairly simple)

Process

The main points of the Major Change Process is 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.

[rustbot]

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.

[eddyb]

There's always the alternative I keep bringing up which is to "just" build two rustc binaries (which are very cheap since they're just calling into librustc_driver.so), and have rustc and rustc-unstable.

Distros can then split the rustc-unstable binary into its own package (AFAIK pretty much every distro out there has "multiple outputs" from one build, a common one being debuginfo), and depend on the old version of that package for building Rust itself.
They don't even need to place it in e.g. /usr/bin, it could be somewhere in /usr/libexec instead, so that it's not in $PATH.
(or we could place it ourselves in lib/rustlib/$triple/bin - and the name could be versioned, e.g. rustc-1.56.0-unstable)

At that point, if someone symlinks the unstable executable to rustc, or sets RUSTC=rustc-unstable, that's no different from aliasing rustc to rustc +nightly ... via rustup, which is to say, individual users can do anything they want anyway.

The important aspect, IMO, is that CI and distro build environments can remove access to it entirely, leaving the regular rustc incapable of turning into rustc-unstable, no matter its environment.

[jyn514]

Closing this in favor of rust-lang/cargo#7088, now that rust-lang/rust#77802 is merged. I think that's a more useful change in any case.