-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Add a way for the test suite to test the output of a stable rustc
#123404
Comments
Another usecase would be to use something like |
RUSTC_BOOTSTRAP=0 feels like a reasonable mechanism/extension to me. |
I'd be concerned with people having set |
FWIW I went with Implementation steps
UI tests can use something like //@ rustc-env:RUSTC_BOOTSTRAP=-1
//@ only-nightly to |
There is |
…ukang Make rustc consider itself a stable compiler when `RUSTC_BOOTSTRAP=-1` Addresses rust-lang#123404 to allow test writers to specify `//@ rustc-env:RUSTC_BOOTSTRAP=-1` to have a given rustc consider itself a stable rustc. This is only intended for testing usages. I did not use `RUSTC_BOOTSTRAP=0` because that can be confusing, i.e. one might think that means "not bootstrapping", but "forcing a given rustc to consider itself a stable compiler" is a different use case. I also added a specific test to check `RUSTC_BOOTSTRAP`'s various values and how that interacts with rustc's stability story w.r.t. features and cli flags. Noticed when trying to write a test for enabling ICE file dumping on stable. Dunno if this needs a compiler FCP or MCP, but I can file an MCP or ask someone to start an FCP if needed. Note that `RUSTC_BOOTSTRAP` is a perma-unstable env var and has no stability guarantees (heh) whatsoever. This does not affect bootstrapping because bootstrap never sets `RUSTC_BOOTSTRAP=-1`. If someone does set that when bootstrapping, it is considered PEBKAC. Accompanying dev-guide PR: rust-lang/rustc-dev-guide#2136 cc `@estebank` and `@rust-lang/wg-diagnostics` for FYI
Rollup merge of rust-lang#132993 - jieyouxu:i_am_very_stable, r=chenyukang Make rustc consider itself a stable compiler when `RUSTC_BOOTSTRAP=-1` Addresses rust-lang#123404 to allow test writers to specify `//@ rustc-env:RUSTC_BOOTSTRAP=-1` to have a given rustc consider itself a stable rustc. This is only intended for testing usages. I did not use `RUSTC_BOOTSTRAP=0` because that can be confusing, i.e. one might think that means "not bootstrapping", but "forcing a given rustc to consider itself a stable compiler" is a different use case. I also added a specific test to check `RUSTC_BOOTSTRAP`'s various values and how that interacts with rustc's stability story w.r.t. features and cli flags. Noticed when trying to write a test for enabling ICE file dumping on stable. Dunno if this needs a compiler FCP or MCP, but I can file an MCP or ask someone to start an FCP if needed. Note that `RUSTC_BOOTSTRAP` is a perma-unstable env var and has no stability guarantees (heh) whatsoever. This does not affect bootstrapping because bootstrap never sets `RUSTC_BOOTSTRAP=-1`. If someone does set that when bootstrapping, it is considered PEBKAC. Accompanying dev-guide PR: rust-lang/rustc-dev-guide#2136 cc `@estebank` and `@rust-lang/wg-diagnostics` for FYI
Update: #132993 has now merged to support |
Right now
ui
tests only target the output of the currently builtrustc
. As far as I can tell, there's no-Z
flag 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 samenote
telling the user that's not allowed, while on nightly it tells the user which feature flag is gating that being allowed, without thenote
stating 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.The text was updated successfully, but these errors were encountered: