Repository navigation
Add a way for the test suite to test the output of a stable rustc #123404
Description
Activity
- added
on Apr 3, 2024 Another usecase would be to use something like
RUSTC_STABLE=1 rustc ice.rs to check if an ICE would happen on $todays nightly in several months after promotion to beta/stable has happened already. 🙂Reacted by Esteban KuberRUSTC_BOOTSTRAP=0 feels like a reasonable mechanism/extension to me.
Reacted by Onur Özkan and Esteban KuberI'd be concerned with people having set
RUSTC_BOOTSTRAP=0globally in their machines and suddenly having issues with nightly, but at the same time "setting that flag has no stability guarantees".- linked a pull request that will close this issueMake rustc consider itself a stable compiler when `RUSTC_BOOTSTRAP=-1` #132993
on Nov 13, 2024 FWIW I went with
RUSTC_BOOTSTRAP=-1to mean "force-stable" in #132993 instead ofRUSTC_BOOTSTRAP=0which can seem like "not bootstrap" which is not quite the same I feel like, and probably confusing.Implementation steps
- Implement
RUSTC_BOOTSTRAP=-1 - Document
RUSTC_BOOTSTRAP=-1
UI tests can use something like
//@ rustc-env:RUSTC_BOOTSTRAP=-1 //@ only-nightly
to
foolconvince the unstable compiler under test to think it's very stable. We can of course also add a//@ pretend-stable-rustcbut yeah.Reacted by Esteban Kuber- Implement
There is
-Zallow-features=to disable support for all#![feature], but this doesn't affect commandline flags and doesn't work on stable either.- removed a link to a pull requestMake rustc consider itself a stable compiler when `RUSTC_BOOTSTRAP=-1` #132993
on Nov 13, 2024 - added a commit that references this issue
on Nov 18, 2024 For future reference, while you can force a given
rustc(well, later than #132993 of course) to pretend to be stable for all intents and purposes, there will still be an important caveat:-> real stable rustc <- actually stable | -> beta rustc | -> nightly rustc | -> `master` rustc <- pretend to be stablethe
masterornightlyorbetarustc will almost certainly contain changes that are not present in the actualstablerustc (unavoidable), which is something important to keep in mind.That being said, I think we can consider this feature request to be sufficiently satisfied via
RUSTC_BOOTSTRAP=-1.Reacted by Esteban KuberThis didn't actually enable testing stable output in UI tests, because compiletest unconditionally passes certain
-Zflags, and that breaks if you truly makerustcact like stable. We needed-2all along (#163664), which acts as stable, but allows unstable compiler flags 😆Reacted by Esteban Kuber and 许杰友 Jieyou Xu (Joe)
Right now
uitests only target the output of the currently builtrustc. As far as I can tell, there's no-Zflag to tellrustc"act as if you were a stable release". This means that when we customize the diagnostic output based on release channel, we cannot test what stable users will actually see. An example of this is this (as of now unmerged) change that on stable refers to unsized locals and unsized fn arguments with the samenotetelling the user that's not allowed, while on nightly it tells the user which feature flag is gating that being allowed, without thenotestating it's not allowed. That kind of behavior is replicated in multiple diagnostics involving nightly features already. It's the same "problem" we'd have with editions if we didn't already have a stable flag to specify them.