Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
1 of 3 tasks
jyn514 opened this issue Aug 26, 2020 · 3 comments
Closed
1 of 3 tasks
Labels
major-change A proposal to make a major change to rustc T-compiler Add this label so rfcbot knows to poll the compiler team

Comments

@jyn514
Copy link
Member

jyn514 commented Aug 26, 2020

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.

@jyn514 jyn514 added T-compiler Add this label so rfcbot knows to poll the compiler team major-change A proposal to make a major change to rustc labels Aug 26, 2020
@rustbot
Copy link
Collaborator

rustbot commented Aug 26, 2020

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 rustbot added the to-announce Announce this issue on triage meeting label Aug 26, 2020
@spastorino spastorino removed the to-announce Announce this issue on triage meeting label Aug 26, 2020
@eddyb
Copy link
Member

eddyb commented Sep 24, 2020

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
Copy link
Member Author

jyn514 commented Dec 24, 2020

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.

@jyn514 jyn514 closed this as completed Dec 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
major-change A proposal to make a major change to rustc T-compiler Add this label so rfcbot knows to poll the compiler team
Projects
None yet
Development

No branches or pull requests

4 participants