Add a way for the test suite to test the output of a stable rustc
#123404
Comments
estebank
added
A-testsuite
rustbot
added
the
needs-triage
onur-ozkan
removed
the
needs-triage
|
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-nightlyto |
|
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
jieyouxu
added
the
A-test-infra
|
Update: #132993 has now merged to support |
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.The text was updated successfully, but these errors were encountered: