Repository navigation
Make rustc consider itself a stable compiler when RUSTC_BOOTSTRAP=-1 - #132993
Merged
Merged
Conversation
rustbot
added
S-waiting-on-review
jieyouxu
added
A-testsuite
Zalathar
reviewed
Nov 13, 2024
Zalathar
reviewed
Nov 13, 2024
Member
|
I was thinking about doing this myself recently, because we have some code paths for adjusting |
jieyouxu
force-pushed
the
i_am_very_stable
branch
3 times, most recently
from
November 13, 2024 12:44
7d8d712 to
151d885
Compare
Zalathar
reviewed
Nov 13, 2024
jieyouxu
force-pushed
the
i_am_very_stable
branch
from
November 13, 2024 12:48
151d885 to
d6f3b18
Compare
jieyouxu
commented
Nov 16, 2024
| // also affected by `RUSTC_BOOTSTRAP`. | ||
| //@[force_stable] rustc-env:RUSTC_BOOTSTRAP=-1 | ||
| //@[force_stable] compile-flags: -Z unstable-options | ||
| //@[force_stable] regex-error-pattern: error: the option `Z` is only accepted on the nightly compiler |
Member
Author
There was a problem hiding this comment.
N.B.: this doesn't check in a snapshot because the exact error message will be different between beta/stable/dev depending on channel info.
jieyouxu
force-pushed
the
i_am_very_stable
branch
from
November 17, 2024 12:00
d6f3b18 to
c130501
Compare
Member
Author
|
Rebased and fixed a comment in order for sentence to sentence, no functional changes. |
Member
|
@bors r+ rollup |
Collaborator
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 18, 2024
Rollup of 7 pull requests Successful merges: - rust-lang#132795 (Check `use<..>` in RPITIT for refinement) - rust-lang#132944 (add parentheses when unboxing suggestion needed) - rust-lang#132993 (Make rustc consider itself a stable compiler when `RUSTC_BOOTSTRAP=-1`) - rust-lang#133130 (`suggest_borrow_generic_arg`: instantiate clauses properly) - rust-lang#133133 (rustdoc-search: add standalone trailing `::` test) - rust-lang#133143 (Diagnostics for let mut in item context) - rust-lang#133147 (Fixup some test directives) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 18, 2024
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
Member
|
Maybe we could replace the empty feature list in with this? Not sure if it has the same behavior though. |
Member
Author
|
Yeah, that is actually somewhat inaccurate if you really wanted to emulate a |
This comment was marked as resolved.
This comment was marked as resolved.
lqd
reviewed
Nov 26, 2024
Member
There was a problem hiding this comment.
(there's a typo on rustc_bootstap.rs ^^)
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Oct 20, 2026
…-real-2, r=jieyouxu Add new `RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags` mode for testing stable compiler behavior in UI tests Right now, it is [not possible](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707) to test how the compiler behaves on the stable toolchain in UI tests. Even though rust-lang#132993 added a mechanism to emulate stable rustc on the nightly channel, using the `RUSTC_BOOTSTRAP=-1` environment variable, this mechanism is not currently usable within compiletest and UI tests directly, because compiletest unconditionally passes several unstable `-Z` flags that are load-bearing for the testing infra itself to work (notably `-Zui-testing` and friends). That is quite annoying, because we do in fact want to test stable behavior in a couple of tests, but today we have to write those as `run-make` tests (latest example: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707), even if the tested situation is very simple. Those are harder to read, write and maintain than UI tests and they do not support blessing outputs as well as UI tests. Recently, I at least added rust-lang#163444 as a way of centralizing the logic of testing a stable `rustc` in a run-make test, but that does not really help with the fact that we still have to use run-make tests for it, even when a normal UI test would do. For rust-lang#162848, I would also like to have a way of passing `-Zthreads=1` to all run-make tests, even if they are testing stable `rustc`, but that's not easily possible, because those tests are using `RUSTC_BOOTSTRAP=-1`. This PR proposes to add a new mode to `RUSTC_BOOTSTRAP`, with the value of `-allow-unstable-compiler-flags=<flags>`. This can be used to emulate the behavior of stable rustc, while still allowing passing *specific* unstable flags to the compiler. The stability check in the compiler is thus now separated into two questions: - Are we an unstable/nightly build? - Can we accept specific unstable compiler flags? The latter is checked only at a few places, so the necessary change to the compiler is rather small (IMO). To demonstrate how this would be used, I also implemented a new directive into compiletest in this PR, `act-as-stable`. That can be used in a UI test to emulate stable rustc. Some tests before used `only-stable` to "achieve" this, which is very misleading, because it doesn't work at all 😆, due to compiletest unconditionally passing `RUSTC_BOOTSTRAP=1` to all executed tests. `act-as-stable` fixes that. The last two commits demonstrate how we could replace run-make tests that tested different output on stable/nightly with UI tests. I suppose that this mode might be interesting for other people outside of `rust-lang/rust`, but if you don't want that, I can gate it behind `-Zui-testing`. r? jieyouxu
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Oct 20, 2026
…-real-2, r=jieyouxu Add new `RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags` mode for testing stable compiler behavior in UI tests Right now, it is [not possible](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707) to test how the compiler behaves on the stable toolchain in UI tests. Even though rust-lang#132993 added a mechanism to emulate stable rustc on the nightly channel, using the `RUSTC_BOOTSTRAP=-1` environment variable, this mechanism is not currently usable within compiletest and UI tests directly, because compiletest unconditionally passes several unstable `-Z` flags that are load-bearing for the testing infra itself to work (notably `-Zui-testing` and friends). That is quite annoying, because we do in fact want to test stable behavior in a couple of tests, but today we have to write those as `run-make` tests (latest example: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707), even if the tested situation is very simple. Those are harder to read, write and maintain than UI tests and they do not support blessing outputs as well as UI tests. Recently, I at least added rust-lang#163444 as a way of centralizing the logic of testing a stable `rustc` in a run-make test, but that does not really help with the fact that we still have to use run-make tests for it, even when a normal UI test would do. For rust-lang#162848, I would also like to have a way of passing `-Zthreads=1` to all run-make tests, even if they are testing stable `rustc`, but that's not easily possible, because those tests are using `RUSTC_BOOTSTRAP=-1`. This PR proposes to add a new mode to `RUSTC_BOOTSTRAP`, with the value of `-allow-unstable-compiler-flags=<flags>`. This can be used to emulate the behavior of stable rustc, while still allowing passing *specific* unstable flags to the compiler. The stability check in the compiler is thus now separated into two questions: - Are we an unstable/nightly build? - Can we accept specific unstable compiler flags? The latter is checked only at a few places, so the necessary change to the compiler is rather small (IMO). To demonstrate how this would be used, I also implemented a new directive into compiletest in this PR, `act-as-stable`. That can be used in a UI test to emulate stable rustc. Some tests before used `only-stable` to "achieve" this, which is very misleading, because it doesn't work at all 😆, due to compiletest unconditionally passing `RUSTC_BOOTSTRAP=1` to all executed tests. `act-as-stable` fixes that. The last two commits demonstrate how we could replace run-make tests that tested different output on stable/nightly with UI tests. I suppose that this mode might be interesting for other people outside of `rust-lang/rust`, but if you don't want that, I can gate it behind `-Zui-testing`. r? jieyouxu
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Oct 20, 2026
…-real-2, r=jieyouxu Add new `RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags` mode for testing stable compiler behavior in UI tests Right now, it is [not possible](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707) to test how the compiler behaves on the stable toolchain in UI tests. Even though rust-lang#132993 added a mechanism to emulate stable rustc on the nightly channel, using the `RUSTC_BOOTSTRAP=-1` environment variable, this mechanism is not currently usable within compiletest and UI tests directly, because compiletest unconditionally passes several unstable `-Z` flags that are load-bearing for the testing infra itself to work (notably `-Zui-testing` and friends). That is quite annoying, because we do in fact want to test stable behavior in a couple of tests, but today we have to write those as `run-make` tests (latest example: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707), even if the tested situation is very simple. Those are harder to read, write and maintain than UI tests and they do not support blessing outputs as well as UI tests. Recently, I at least added rust-lang#163444 as a way of centralizing the logic of testing a stable `rustc` in a run-make test, but that does not really help with the fact that we still have to use run-make tests for it, even when a normal UI test would do. For rust-lang#162848, I would also like to have a way of passing `-Zthreads=1` to all run-make tests, even if they are testing stable `rustc`, but that's not easily possible, because those tests are using `RUSTC_BOOTSTRAP=-1`. This PR proposes to add a new mode to `RUSTC_BOOTSTRAP`, with the value of `-allow-unstable-compiler-flags=<flags>`. This can be used to emulate the behavior of stable rustc, while still allowing passing *specific* unstable flags to the compiler. The stability check in the compiler is thus now separated into two questions: - Are we an unstable/nightly build? - Can we accept specific unstable compiler flags? The latter is checked only at a few places, so the necessary change to the compiler is rather small (IMO). To demonstrate how this would be used, I also implemented a new directive into compiletest in this PR, `act-as-stable`. That can be used in a UI test to emulate stable rustc. Some tests before used `only-stable` to "achieve" this, which is very misleading, because it doesn't work at all 😆, due to compiletest unconditionally passing `RUSTC_BOOTSTRAP=1` to all executed tests. `act-as-stable` fixes that. The last two commits demonstrate how we could replace run-make tests that tested different output on stable/nightly with UI tests. I suppose that this mode might be interesting for other people outside of `rust-lang/rust`, but if you don't want that, I can gate it behind `-Zui-testing`. r? jieyouxu
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Oct 20, 2026
…-real-2, r=jieyouxu Add new `RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags` mode for testing stable compiler behavior in UI tests Right now, it is [not possible](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707) to test how the compiler behaves on the stable toolchain in UI tests. Even though rust-lang#132993 added a mechanism to emulate stable rustc on the nightly channel, using the `RUSTC_BOOTSTRAP=-1` environment variable, this mechanism is not currently usable within compiletest and UI tests directly, because compiletest unconditionally passes several unstable `-Z` flags that are load-bearing for the testing infra itself to work (notably `-Zui-testing` and friends). That is quite annoying, because we do in fact want to test stable behavior in a couple of tests, but today we have to write those as `run-make` tests (latest example: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707), even if the tested situation is very simple. Those are harder to read, write and maintain than UI tests and they do not support blessing outputs as well as UI tests. Recently, I at least added rust-lang#163444 as a way of centralizing the logic of testing a stable `rustc` in a run-make test, but that does not really help with the fact that we still have to use run-make tests for it, even when a normal UI test would do. For rust-lang#162848, I would also like to have a way of passing `-Zthreads=1` to all run-make tests, even if they are testing stable `rustc`, but that's not easily possible, because those tests are using `RUSTC_BOOTSTRAP=-1`. This PR proposes to add a new mode to `RUSTC_BOOTSTRAP`, with the value of `-allow-unstable-compiler-flags=<flags>`. This can be used to emulate the behavior of stable rustc, while still allowing passing *specific* unstable flags to the compiler. The stability check in the compiler is thus now separated into two questions: - Are we an unstable/nightly build? - Can we accept specific unstable compiler flags? The latter is checked only at a few places, so the necessary change to the compiler is rather small (IMO). To demonstrate how this would be used, I also implemented a new directive into compiletest in this PR, `act-as-stable`. That can be used in a UI test to emulate stable rustc. Some tests before used `only-stable` to "achieve" this, which is very misleading, because it doesn't work at all 😆, due to compiletest unconditionally passing `RUSTC_BOOTSTRAP=1` to all executed tests. `act-as-stable` fixes that. The last two commits demonstrate how we could replace run-make tests that tested different output on stable/nightly with UI tests. I suppose that this mode might be interesting for other people outside of `rust-lang/rust`, but if you don't want that, I can gate it behind `-Zui-testing`. r? jieyouxu
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Oct 20, 2026
…-real-2, r=jieyouxu Add new `RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags` mode for testing stable compiler behavior in UI tests Right now, it is [not possible](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707) to test how the compiler behaves on the stable toolchain in UI tests. Even though rust-lang#132993 added a mechanism to emulate stable rustc on the nightly channel, using the `RUSTC_BOOTSTRAP=-1` environment variable, this mechanism is not currently usable within compiletest and UI tests directly, because compiletest unconditionally passes several unstable `-Z` flags that are load-bearing for the testing infra itself to work (notably `-Zui-testing` and friends). That is quite annoying, because we do in fact want to test stable behavior in a couple of tests, but today we have to write those as `run-make` tests (latest example: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707), even if the tested situation is very simple. Those are harder to read, write and maintain than UI tests and they do not support blessing outputs as well as UI tests. Recently, I at least added rust-lang#163444 as a way of centralizing the logic of testing a stable `rustc` in a run-make test, but that does not really help with the fact that we still have to use run-make tests for it, even when a normal UI test would do. For rust-lang#162848, I would also like to have a way of passing `-Zthreads=1` to all run-make tests, even if they are testing stable `rustc`, but that's not easily possible, because those tests are using `RUSTC_BOOTSTRAP=-1`. This PR proposes to add a new mode to `RUSTC_BOOTSTRAP`, with the value of `-allow-unstable-compiler-flags=<flags>`. This can be used to emulate the behavior of stable rustc, while still allowing passing *specific* unstable flags to the compiler. The stability check in the compiler is thus now separated into two questions: - Are we an unstable/nightly build? - Can we accept specific unstable compiler flags? The latter is checked only at a few places, so the necessary change to the compiler is rather small (IMO). To demonstrate how this would be used, I also implemented a new directive into compiletest in this PR, `act-as-stable`. That can be used in a UI test to emulate stable rustc. Some tests before used `only-stable` to "achieve" this, which is very misleading, because it doesn't work at all 😆, due to compiletest unconditionally passing `RUSTC_BOOTSTRAP=1` to all executed tests. `act-as-stable` fixes that. The last two commits demonstrate how we could replace run-make tests that tested different output on stable/nightly with UI tests. I suppose that this mode might be interesting for other people outside of `rust-lang/rust`, but if you don't want that, I can gate it behind `-Zui-testing`. r? jieyouxu
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Oct 20, 2026
…-real-2, r=jieyouxu Add new `RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags` mode for testing stable compiler behavior in UI tests Right now, it is [not possible](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707) to test how the compiler behaves on the stable toolchain in UI tests. Even though rust-lang#132993 added a mechanism to emulate stable rustc on the nightly channel, using the `RUSTC_BOOTSTRAP=-1` environment variable, this mechanism is not currently usable within compiletest and UI tests directly, because compiletest unconditionally passes several unstable `-Z` flags that are load-bearing for the testing infra itself to work (notably `-Zui-testing` and friends). That is quite annoying, because we do in fact want to test stable behavior in a couple of tests, but today we have to write those as `run-make` tests (latest example: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707), even if the tested situation is very simple. Those are harder to read, write and maintain than UI tests and they do not support blessing outputs as well as UI tests. Recently, I at least added rust-lang#163444 as a way of centralizing the logic of testing a stable `rustc` in a run-make test, but that does not really help with the fact that we still have to use run-make tests for it, even when a normal UI test would do. For rust-lang#162848, I would also like to have a way of passing `-Zthreads=1` to all run-make tests, even if they are testing stable `rustc`, but that's not easily possible, because those tests are using `RUSTC_BOOTSTRAP=-1`. This PR proposes to add a new mode to `RUSTC_BOOTSTRAP`, with the value of `-allow-unstable-compiler-flags=<flags>`. This can be used to emulate the behavior of stable rustc, while still allowing passing *specific* unstable flags to the compiler. The stability check in the compiler is thus now separated into two questions: - Are we an unstable/nightly build? - Can we accept specific unstable compiler flags? The latter is checked only at a few places, so the necessary change to the compiler is rather small (IMO). To demonstrate how this would be used, I also implemented a new directive into compiletest in this PR, `act-as-stable`. That can be used in a UI test to emulate stable rustc. Some tests before used `only-stable` to "achieve" this, which is very misleading, because it doesn't work at all 😆, due to compiletest unconditionally passing `RUSTC_BOOTSTRAP=1` to all executed tests. `act-as-stable` fixes that. The last two commits demonstrate how we could replace run-make tests that tested different output on stable/nightly with UI tests. I suppose that this mode might be interesting for other people outside of `rust-lang/rust`, but if you don't want that, I can gate it behind `-Zui-testing`. r? jieyouxu
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Oct 20, 2026
…-real-2, r=jieyouxu Add new `RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags` mode for testing stable compiler behavior in UI tests Right now, it is [not possible](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707) to test how the compiler behaves on the stable toolchain in UI tests. Even though rust-lang#132993 added a mechanism to emulate stable rustc on the nightly channel, using the `RUSTC_BOOTSTRAP=-1` environment variable, this mechanism is not currently usable within compiletest and UI tests directly, because compiletest unconditionally passes several unstable `-Z` flags that are load-bearing for the testing infra itself to work (notably `-Zui-testing` and friends). That is quite annoying, because we do in fact want to test stable behavior in a couple of tests, but today we have to write those as `run-make` tests (latest example: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707), even if the tested situation is very simple. Those are harder to read, write and maintain than UI tests and they do not support blessing outputs as well as UI tests. Recently, I at least added rust-lang#163444 as a way of centralizing the logic of testing a stable `rustc` in a run-make test, but that does not really help with the fact that we still have to use run-make tests for it, even when a normal UI test would do. For rust-lang#162848, I would also like to have a way of passing `-Zthreads=1` to all run-make tests, even if they are testing stable `rustc`, but that's not easily possible, because those tests are using `RUSTC_BOOTSTRAP=-1`. This PR proposes to add a new mode to `RUSTC_BOOTSTRAP`, with the value of `-allow-unstable-compiler-flags=<flags>`. This can be used to emulate the behavior of stable rustc, while still allowing passing *specific* unstable flags to the compiler. The stability check in the compiler is thus now separated into two questions: - Are we an unstable/nightly build? - Can we accept specific unstable compiler flags? The latter is checked only at a few places, so the necessary change to the compiler is rather small (IMO). To demonstrate how this would be used, I also implemented a new directive into compiletest in this PR, `act-as-stable`. That can be used in a UI test to emulate stable rustc. Some tests before used `only-stable` to "achieve" this, which is very misleading, because it doesn't work at all 😆, due to compiletest unconditionally passing `RUSTC_BOOTSTRAP=1` to all executed tests. `act-as-stable` fixes that. The last two commits demonstrate how we could replace run-make tests that tested different output on stable/nightly with UI tests. I suppose that this mode might be interesting for other people outside of `rust-lang/rust`, but if you don't want that, I can gate it behind `-Zui-testing`. r? jieyouxu
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Oct 21, 2026
…-real-2, r=jieyouxu Add new `RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags` mode for testing stable compiler behavior in UI tests Right now, it is [not possible](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707) to test how the compiler behaves on the stable toolchain in UI tests. Even though rust-lang#132993 added a mechanism to emulate stable rustc on the nightly channel, using the `RUSTC_BOOTSTRAP=-1` environment variable, this mechanism is not currently usable within compiletest and UI tests directly, because compiletest unconditionally passes several unstable `-Z` flags that are load-bearing for the testing infra itself to work (notably `-Zui-testing` and friends). That is quite annoying, because we do in fact want to test stable behavior in a couple of tests, but today we have to write those as `run-make` tests (latest example: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707), even if the tested situation is very simple. Those are harder to read, write and maintain than UI tests and they do not support blessing outputs as well as UI tests. Recently, I at least added rust-lang#163444 as a way of centralizing the logic of testing a stable `rustc` in a run-make test, but that does not really help with the fact that we still have to use run-make tests for it, even when a normal UI test would do. For rust-lang#162848, I would also like to have a way of passing `-Zthreads=1` to all run-make tests, even if they are testing stable `rustc`, but that's not easily possible, because those tests are using `RUSTC_BOOTSTRAP=-1`. This PR proposes to add a new mode to `RUSTC_BOOTSTRAP`, with the value of `-allow-unstable-compiler-flags=<flags>`. This can be used to emulate the behavior of stable rustc, while still allowing passing *specific* unstable flags to the compiler. The stability check in the compiler is thus now separated into two questions: - Are we an unstable/nightly build? - Can we accept specific unstable compiler flags? The latter is checked only at a few places, so the necessary change to the compiler is rather small (IMO). To demonstrate how this would be used, I also implemented a new directive into compiletest in this PR, `act-as-stable`. That can be used in a UI test to emulate stable rustc. Some tests before used `only-stable` to "achieve" this, which is very misleading, because it doesn't work at all 😆, due to compiletest unconditionally passing `RUSTC_BOOTSTRAP=1` to all executed tests. `act-as-stable` fixes that. The last two commits demonstrate how we could replace run-make tests that tested different output on stable/nightly with UI tests. I suppose that this mode might be interesting for other people outside of `rust-lang/rust`, but if you don't want that, I can gate it behind `-Zui-testing`. r? jieyouxu
rust-bors Bot
pushed a commit
that referenced
this pull request
Oct 21, 2026
Rollup merge of #163664 - Kobzol:bootstrap-but-this-time-for-real-2, r=jieyouxu Add new `RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags` mode for testing stable compiler behavior in UI tests Right now, it is [not possible](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707) to test how the compiler behaves on the stable toolchain in UI tests. Even though #132993 added a mechanism to emulate stable rustc on the nightly channel, using the `RUSTC_BOOTSTRAP=-1` environment variable, this mechanism is not currently usable within compiletest and UI tests directly, because compiletest unconditionally passes several unstable `-Z` flags that are load-bearing for the testing infra itself to work (notably `-Zui-testing` and friends). That is quite annoying, because we do in fact want to test stable behavior in a couple of tests, but today we have to write those as `run-make` tests (latest example: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707), even if the tested situation is very simple. Those are harder to read, write and maintain than UI tests and they do not support blessing outputs as well as UI tests. Recently, I at least added #163444 as a way of centralizing the logic of testing a stable `rustc` in a run-make test, but that does not really help with the fact that we still have to use run-make tests for it, even when a normal UI test would do. For #162848, I would also like to have a way of passing `-Zthreads=1` to all run-make tests, even if they are testing stable `rustc`, but that's not easily possible, because those tests are using `RUSTC_BOOTSTRAP=-1`. This PR proposes to add a new mode to `RUSTC_BOOTSTRAP`, with the value of `-allow-unstable-compiler-flags=<flags>`. This can be used to emulate the behavior of stable rustc, while still allowing passing *specific* unstable flags to the compiler. The stability check in the compiler is thus now separated into two questions: - Are we an unstable/nightly build? - Can we accept specific unstable compiler flags? The latter is checked only at a few places, so the necessary change to the compiler is rather small (IMO). To demonstrate how this would be used, I also implemented a new directive into compiletest in this PR, `act-as-stable`. That can be used in a UI test to emulate stable rustc. Some tests before used `only-stable` to "achieve" this, which is very misleading, because it doesn't work at all 😆, due to compiletest unconditionally passing `RUSTC_BOOTSTRAP=1` to all executed tests. `act-as-stable` fixes that. The last two commits demonstrate how we could replace run-make tests that tested different output on stable/nightly with UI tests. I suppose that this mode might be interesting for other people outside of `rust-lang/rust`, but if you don't want that, I can gate it behind `-Zui-testing`. r? jieyouxu
github-actions Bot
pushed a commit
to rust-lang/stdarch
that referenced
this pull request
Oct 22, 2026
…r=jieyouxu Add new `RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags` mode for testing stable compiler behavior in UI tests Right now, it is [not possible](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707) to test how the compiler behaves on the stable toolchain in UI tests. Even though rust-lang/rust#132993 added a mechanism to emulate stable rustc on the nightly channel, using the `RUSTC_BOOTSTRAP=-1` environment variable, this mechanism is not currently usable within compiletest and UI tests directly, because compiletest unconditionally passes several unstable `-Z` flags that are load-bearing for the testing infra itself to work (notably `-Zui-testing` and friends). That is quite annoying, because we do in fact want to test stable behavior in a couple of tests, but today we have to write those as `run-make` tests (latest example: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707), even if the tested situation is very simple. Those are harder to read, write and maintain than UI tests and they do not support blessing outputs as well as UI tests. Recently, I at least added rust-lang/rust#163444 as a way of centralizing the logic of testing a stable `rustc` in a run-make test, but that does not really help with the fact that we still have to use run-make tests for it, even when a normal UI test would do. For rust-lang/rust#162848, I would also like to have a way of passing `-Zthreads=1` to all run-make tests, even if they are testing stable `rustc`, but that's not easily possible, because those tests are using `RUSTC_BOOTSTRAP=-1`. This PR proposes to add a new mode to `RUSTC_BOOTSTRAP`, with the value of `-allow-unstable-compiler-flags=<flags>`. This can be used to emulate the behavior of stable rustc, while still allowing passing *specific* unstable flags to the compiler. The stability check in the compiler is thus now separated into two questions: - Are we an unstable/nightly build? - Can we accept specific unstable compiler flags? The latter is checked only at a few places, so the necessary change to the compiler is rather small (IMO). To demonstrate how this would be used, I also implemented a new directive into compiletest in this PR, `act-as-stable`. That can be used in a UI test to emulate stable rustc. Some tests before used `only-stable` to "achieve" this, which is very misleading, because it doesn't work at all 😆, due to compiletest unconditionally passing `RUSTC_BOOTSTRAP=1` to all executed tests. `act-as-stable` fixes that. The last two commits demonstrate how we could replace run-make tests that tested different output on stable/nightly with UI tests. I suppose that this mode might be interesting for other people outside of `rust-lang/rust`, but if you don't want that, I can gate it behind `-Zui-testing`. r? jieyouxu
programskillforverification
pushed a commit
to programskillforverification/miri
that referenced
this pull request
Oct 22, 2026
…r=jieyouxu Add new `RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags` mode for testing stable compiler behavior in UI tests Right now, it is [not possible](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707) to test how the compiler behaves on the stable toolchain in UI tests. Even though rust-lang/rust#132993 added a mechanism to emulate stable rustc on the nightly channel, using the `RUSTC_BOOTSTRAP=-1` environment variable, this mechanism is not currently usable within compiletest and UI tests directly, because compiletest unconditionally passes several unstable `-Z` flags that are load-bearing for the testing infra itself to work (notably `-Zui-testing` and friends). That is quite annoying, because we do in fact want to test stable behavior in a couple of tests, but today we have to write those as `run-make` tests (latest example: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707), even if the tested situation is very simple. Those are harder to read, write and maintain than UI tests and they do not support blessing outputs as well as UI tests. Recently, I at least added rust-lang/rust#163444 as a way of centralizing the logic of testing a stable `rustc` in a run-make test, but that does not really help with the fact that we still have to use run-make tests for it, even when a normal UI test would do. For rust-lang/rust#162848, I would also like to have a way of passing `-Zthreads=1` to all run-make tests, even if they are testing stable `rustc`, but that's not easily possible, because those tests are using `RUSTC_BOOTSTRAP=-1`. This PR proposes to add a new mode to `RUSTC_BOOTSTRAP`, with the value of `-allow-unstable-compiler-flags=<flags>`. This can be used to emulate the behavior of stable rustc, while still allowing passing *specific* unstable flags to the compiler. The stability check in the compiler is thus now separated into two questions: - Are we an unstable/nightly build? - Can we accept specific unstable compiler flags? The latter is checked only at a few places, so the necessary change to the compiler is rather small (IMO). To demonstrate how this would be used, I also implemented a new directive into compiletest in this PR, `act-as-stable`. That can be used in a UI test to emulate stable rustc. Some tests before used `only-stable` to "achieve" this, which is very misleading, because it doesn't work at all 😆, due to compiletest unconditionally passing `RUSTC_BOOTSTRAP=1` to all executed tests. `act-as-stable` fixes that. The last two commits demonstrate how we could replace run-make tests that tested different output on stable/nightly with UI tests. I suppose that this mode might be interesting for other people outside of `rust-lang/rust`, but if you don't want that, I can gate it behind `-Zui-testing`. r? jieyouxu
bjorn3
pushed a commit
to rust-lang/rustc_codegen_cranelift
that referenced
this pull request
Oct 23, 2026
…r=jieyouxu Add new `RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags` mode for testing stable compiler behavior in UI tests Right now, it is [not possible](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707) to test how the compiler behaves on the stable toolchain in UI tests. Even though rust-lang/rust#132993 added a mechanism to emulate stable rustc on the nightly channel, using the `RUSTC_BOOTSTRAP=-1` environment variable, this mechanism is not currently usable within compiletest and UI tests directly, because compiletest unconditionally passes several unstable `-Z` flags that are load-bearing for the testing infra itself to work (notably `-Zui-testing` and friends). That is quite annoying, because we do in fact want to test stable behavior in a couple of tests, but today we have to write those as `run-make` tests (latest example: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707), even if the tested situation is very simple. Those are harder to read, write and maintain than UI tests and they do not support blessing outputs as well as UI tests. Recently, I at least added rust-lang/rust#163444 as a way of centralizing the logic of testing a stable `rustc` in a run-make test, but that does not really help with the fact that we still have to use run-make tests for it, even when a normal UI test would do. For rust-lang/rust#162848, I would also like to have a way of passing `-Zthreads=1` to all run-make tests, even if they are testing stable `rustc`, but that's not easily possible, because those tests are using `RUSTC_BOOTSTRAP=-1`. This PR proposes to add a new mode to `RUSTC_BOOTSTRAP`, with the value of `-allow-unstable-compiler-flags=<flags>`. This can be used to emulate the behavior of stable rustc, while still allowing passing *specific* unstable flags to the compiler. The stability check in the compiler is thus now separated into two questions: - Are we an unstable/nightly build? - Can we accept specific unstable compiler flags? The latter is checked only at a few places, so the necessary change to the compiler is rather small (IMO). To demonstrate how this would be used, I also implemented a new directive into compiletest in this PR, `act-as-stable`. That can be used in a UI test to emulate stable rustc. Some tests before used `only-stable` to "achieve" this, which is very misleading, because it doesn't work at all 😆, due to compiletest unconditionally passing `RUSTC_BOOTSTRAP=1` to all executed tests. `act-as-stable` fixes that. The last two commits demonstrate how we could replace run-make tests that tested different output on stable/nightly with UI tests. I suppose that this mode might be interesting for other people outside of `rust-lang/rust`, but if you don't want that, I can gate it behind `-Zui-testing`. r? jieyouxu
github-actions Bot
pushed a commit
to rust-lang/rustc-dev-guide
that referenced
this pull request
Oct 25, 2026
…r=jieyouxu Add new `RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags` mode for testing stable compiler behavior in UI tests Right now, it is [not possible](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707) to test how the compiler behaves on the stable toolchain in UI tests. Even though rust-lang/rust#132993 added a mechanism to emulate stable rustc on the nightly channel, using the `RUSTC_BOOTSTRAP=-1` environment variable, this mechanism is not currently usable within compiletest and UI tests directly, because compiletest unconditionally passes several unstable `-Z` flags that are load-bearing for the testing infra itself to work (notably `-Zui-testing` and friends). That is quite annoying, because we do in fact want to test stable behavior in a couple of tests, but today we have to write those as `run-make` tests (latest example: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707), even if the tested situation is very simple. Those are harder to read, write and maintain than UI tests and they do not support blessing outputs as well as UI tests. Recently, I at least added rust-lang/rust#163444 as a way of centralizing the logic of testing a stable `rustc` in a run-make test, but that does not really help with the fact that we still have to use run-make tests for it, even when a normal UI test would do. For rust-lang/rust#162848, I would also like to have a way of passing `-Zthreads=1` to all run-make tests, even if they are testing stable `rustc`, but that's not easily possible, because those tests are using `RUSTC_BOOTSTRAP=-1`. This PR proposes to add a new mode to `RUSTC_BOOTSTRAP`, with the value of `-allow-unstable-compiler-flags=<flags>`. This can be used to emulate the behavior of stable rustc, while still allowing passing *specific* unstable flags to the compiler. The stability check in the compiler is thus now separated into two questions: - Are we an unstable/nightly build? - Can we accept specific unstable compiler flags? The latter is checked only at a few places, so the necessary change to the compiler is rather small (IMO). To demonstrate how this would be used, I also implemented a new directive into compiletest in this PR, `act-as-stable`. That can be used in a UI test to emulate stable rustc. Some tests before used `only-stable` to "achieve" this, which is very misleading, because it doesn't work at all 😆, due to compiletest unconditionally passing `RUSTC_BOOTSTRAP=1` to all executed tests. `act-as-stable` fixes that. The last two commits demonstrate how we could replace run-make tests that tested different output on stable/nightly with UI tests. I suppose that this mode might be interesting for other people outside of `rust-lang/rust`, but if you don't want that, I can gate it behind `-Zui-testing`. r? jieyouxu
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses #123404 to allow test writers to specify
//@ rustc-env:RUSTC_BOOTSTRAP=-1to have a given rustc consider itself a stable rustc. This is only intended for testing usages.I did not use
RUSTC_BOOTSTRAP=0because 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_BOOTSTRAPis a perma-unstable env var and has no stability guarantees (heh) whatsoever. This does not affect bootstrapping because bootstrap never setsRUSTC_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