Description
Proposal
It is a simple fact that people outside the rust project are using RUSTC_BOOTSTRAP. Given that, we should make it more clear what it does.
I propose the following:
-
Document the variable in the unstable book so people know what it does, why it exists, and why we would really prefer them not to use it. Right now it spreads by word of mouth, and I do not think people know exactly what breakage they are opting into. document RUSTC_BOOTSTRAP, RUSTC_OVERRIDE_VERSION_STRING, and -Z allow-features in the unstable book rust#139885
-
Document that libraries that use nightly features should use an explicit opt-in: Document that nightly features should be opt-in using aEDIT(jieyouxu): not compiler concern--cfg
flag api-guidelines#284 -
change the name to RUSTC_ALLOW_UNSTABLE_ON_STABLE (name subject to bikeshedding) that has exactly the current semantics -
give a hard warning (i.e. not silence-able or deny-able) if people use RUSTC_BOOTSTRAP -
simultaneously, change cargo and all related tooling to use the new name. the hard error for build scripts setting RUSTC_BOOTSTRAP will apply to both the old and new name.
Mentors or Reviewers
@onur-ozkan, @bjorn3, @Mark-Simulacrum
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.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- 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.