Reject running compiletest self-tests against stage 0 rustc unless explicitly allowed#144675
Merged
bors merged 5 commits intorust-lang:masterfrom Jul 30, 2025
Merged
Reject running compiletest self-tests against stage 0 rustc unless explicitly allowed#144675bors merged 5 commits intorust-lang:masterfrom
compiletest self-tests against stage 0 rustc unless explicitly allowed#144675bors merged 5 commits intorust-lang:masterfrom
Conversation
925f797 to
0539cc1
Compare
Member
Author
|
cc @bjorn3 on the cg_clif changes (commit 2 mostly) |
Collaborator
|
This PR modifies If appropriate, please update This PR modifies If appropriate, please update Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 |
bjorn3
reviewed
Jul 30, 2025
0539cc1 to
89f67a4
Compare
Member
Author
Hello? |
Kobzol
reviewed
Jul 30, 2025
Member
Kobzol
left a comment
There was a problem hiding this comment.
opt-dist and cg_gcc will also need to be updated (you can grep for usage of COMPILETEST_FORCE_STAGE0).
89f67a4 to
450c589
Compare
Collaborator
|
Some changes occurred in compiler/rustc_codegen_gcc Some changes occurred in src/tools/opt-dist cc @Kobzol |
Member
Author
|
Changes since last review:
|
450c589 to
2e92be1
Compare
compiletest self-tests against stage 0 rustc unless forcedcompiletest self-tests against stage 0 rustc unless explicitly allowed
In favor of the adhoc `COMPILETEST_FORCE_STAGE0` env var.
…test-allow-stage0`
…explicitly allowed Otherwise, `compiletest` would have to know e.g. how to parse two different target spec, if target spec format was changed between beta `rustc` and in-tree `rustc`.
And move `./x test compiletest --stage=1` to `pr-check-2`, where testing library artifacts already requires building the stage 1 compiler.
274e067 to
e954253
Compare
Member
Author
|
@rustbot review |
Member
|
Thanks! @bors r+ |
Collaborator
bors
added a commit
that referenced
this pull request
Jul 30, 2025
Rollup of 4 pull requests Successful merges: - #143465 (Support multiple crate versions in --extern-html-root-url) - #144308 ([rustdoc] Display total time and compilation time of merged doctests) - #144655 (clean up codegen fn attrs) - #144675 (Reject running `compiletest` self-tests against stage 0 rustc unless explicitly allowed) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
that referenced
this pull request
Jul 30, 2025
Rollup merge of #144675 - jieyouxu:compiletest-staging, r=Kobzol Reject running `compiletest` self-tests against stage 0 rustc unless explicitly allowed Currently, in `pr-check-1`, we run `python3 ../x.py test --stage 0 src/tools/compiletest`, which is `compiletest` self-tests against stage 0 rustc. This makes it very annoying for PRs wanting to change target spec JSON format, which `compiletest` depends on for target information, as otherwise `compiletest` would have to know how to handle 2 different target spec JSON formats and know when to pick which. Instead of doing that, we change `compiletest` self-tests to reject running against stage 0 `rustc` *unless* explicitly allowed with `build.compiletest-allow-stage0=true`. `build.compiletest-allow-stage0` is a proper bootstrap config option in favor of the ad-hoc `COMPILETEST_FORCE_STAGE0` env var. This means that: - `./x test src/tools/compiletest --stage=0` is not allowed, unless `build.compiletest-allow-stage0=true` is set. In this scenario, `compiletest` self-tests should be expected to fail unless the stage 0 `rustc` as provided is like codegen_cranelift where it's *actually* built from in-tree `rustc` sources. - In CI, we change `./x test src/tools/compiletest --stage=0` to `./x test src/tools/compiletest --stage=1`, and move it to `pr-check-2`. Yes, this involves building the stage 1 compiler, but `pr-check-2` already has to build stage 1 compiler to test stage 1 library crates. - Crucially, this means that **`compiletest` is only intended to support one target spec JSON format**, namely the one corresponding to the in-tree `rustc`. - This should preserve the `compiletest-use-stage0-libtest` UX optimization where changing `compiler/` tree should still not require rebuilding `compiletest` as long as `build.compiletest-use-stage0-libtest=true`, as that should remain orthogonal. This is completely unlike my previous attempt at #144563 that tries to do a way more invasive change which would cause the rebuild problem. Best reviewed commit-by-commit. --- r? `@Kobzol`
This was referenced Jul 31, 2025
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Aug 1, 2025
…Kobzol Properly pass path to staged `rustc` to `compiletest` self-tests Otherwise, this can do weird things like use a global rustc, or try to use stage 0 rustc. This must be properly configured, because `compiletest` is intended to only support one compiler target spec JSON format (of the in-tree compiler). Historically, this was probably done so before `bootstrap` was really its own thing, and `compiletest` had to be runnable as a much more "self-standing" tool. Follow-up to rust-lang#144675, as I didn't realize this until Zalathar pointed it out in [#t-infra/bootstrap > Building vs testing &rust-lang#96;compiletest&rust-lang#96; @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Building.20vs.20testing.20.60compiletest.60/near/532040838). r? `@Kobzol`
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Aug 1, 2025
…Kobzol Properly pass path to staged `rustc` to `compiletest` self-tests Otherwise, this can do weird things like use a global rustc, or try to use stage 0 rustc. This must be properly configured, because `compiletest` is intended to only support one compiler target spec JSON format (of the in-tree compiler). Historically, this was probably done so before `bootstrap` was really its own thing, and `compiletest` had to be runnable as a much more "self-standing" tool. Follow-up to rust-lang#144675, as I didn't realize this until Zalathar pointed it out in [#t-infra/bootstrap > Building vs testing &rust-lang#96;compiletest&rust-lang#96; @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Building.20vs.20testing.20.60compiletest.60/near/532040838). r? ``@Kobzol``
samueltardieu
added a commit
to samueltardieu/rust
that referenced
this pull request
Aug 2, 2025
…Kobzol Properly pass path to staged `rustc` to `compiletest` self-tests Otherwise, this can do weird things like use a global rustc, or try to use stage 0 rustc. This must be properly configured, because `compiletest` is intended to only support one compiler target spec JSON format (of the in-tree compiler). Historically, this was probably done so before `bootstrap` was really its own thing, and `compiletest` had to be runnable as a much more "self-standing" tool. Follow-up to rust-lang#144675, as I didn't realize this until Zalathar pointed it out in [#t-infra/bootstrap > Building vs testing &rust-lang#96;compiletest&rust-lang#96; @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Building.20vs.20testing.20.60compiletest.60/near/532040838). r? ```@Kobzol```
samueltardieu
added a commit
to samueltardieu/rust
that referenced
this pull request
Aug 2, 2025
…Kobzol Properly pass path to staged `rustc` to `compiletest` self-tests Otherwise, this can do weird things like use a global rustc, or try to use stage 0 rustc. This must be properly configured, because `compiletest` is intended to only support one compiler target spec JSON format (of the in-tree compiler). Historically, this was probably done so before `bootstrap` was really its own thing, and `compiletest` had to be runnable as a much more "self-standing" tool. Follow-up to rust-lang#144675, as I didn't realize this until Zalathar pointed it out in [#t-infra/bootstrap > Building vs testing &rust-lang#96;compiletest&rust-lang#96; @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Building.20vs.20testing.20.60compiletest.60/near/532040838). r? ````@Kobzol````
rust-timer
added a commit
that referenced
this pull request
Aug 3, 2025
Rollup merge of #144782 - jieyouxu:compiletest-selftests, r=Kobzol Properly pass path to staged `rustc` to `compiletest` self-tests Otherwise, this can do weird things like use a global rustc, or try to use stage 0 rustc. This must be properly configured, because `compiletest` is intended to only support one compiler target spec JSON format (of the in-tree compiler). Historically, this was probably done so before `bootstrap` was really its own thing, and `compiletest` had to be runnable as a much more "self-standing" tool. Follow-up to #144675, as I didn't realize this until Zalathar pointed it out in [#t-infra/bootstrap > Building vs testing `compiletest` @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Building.20vs.20testing.20.60compiletest.60/near/532040838). r? ````@Kobzol````
Kobzol
pushed a commit
to Kobzol/rustc_codegen_gcc
that referenced
this pull request
Dec 21, 2025
Rollup of 4 pull requests Successful merges: - rust-lang/rust#143465 (Support multiple crate versions in --extern-html-root-url) - rust-lang/rust#144308 ([rustdoc] Display total time and compilation time of merged doctests) - rust-lang/rust#144655 (clean up codegen fn attrs) - rust-lang/rust#144675 (Reject running `compiletest` self-tests against stage 0 rustc unless explicitly allowed) r? `@ghost` `@rustbot` modify labels: rollup
Kobzol
pushed a commit
to Kobzol/rustc_codegen_cranelift
that referenced
this pull request
Dec 29, 2025
Rollup of 4 pull requests Successful merges: - rust-lang/rust#143465 (Support multiple crate versions in --extern-html-root-url) - rust-lang/rust#144308 ([rustdoc] Display total time and compilation time of merged doctests) - rust-lang/rust#144655 (clean up codegen fn attrs) - rust-lang/rust#144675 (Reject running `compiletest` self-tests against stage 0 rustc unless explicitly allowed) r? `@ghost` `@rustbot` modify labels: rollup
christian-schilling
pushed a commit
to christian-schilling/rustc_codegen_cranelift
that referenced
this pull request
Jan 27, 2026
Rollup of 4 pull requests Successful merges: - rust-lang/rust#143465 (Support multiple crate versions in --extern-html-root-url) - rust-lang/rust#144308 ([rustdoc] Display total time and compilation time of merged doctests) - rust-lang/rust#144655 (clean up codegen fn attrs) - rust-lang/rust#144675 (Reject running `compiletest` self-tests against stage 0 rustc unless explicitly allowed) r? `@ghost` `@rustbot` modify labels: rollup
christian-schilling
pushed a commit
to christian-schilling/rustc_codegen_cranelift
that referenced
this pull request
Jan 27, 2026
Rollup of 4 pull requests Successful merges: - rust-lang/rust#143465 (Support multiple crate versions in --extern-html-root-url) - rust-lang/rust#144308 ([rustdoc] Display total time and compilation time of merged doctests) - rust-lang/rust#144655 (clean up codegen fn attrs) - rust-lang/rust#144675 (Reject running `compiletest` self-tests against stage 0 rustc unless explicitly allowed) r? `@ghost` `@rustbot` modify labels: rollup
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.
Currently, in
pr-check-1, we runpython3 ../x.py test --stage 0 src/tools/compiletest, which iscompiletestself-tests against stage 0 rustc. This makes it very annoying for PRs wanting to change target spec JSON format, whichcompiletestdepends on for target information, as otherwisecompiletestwould have to know how to handle 2 different target spec JSON formats and know when to pick which.Instead of doing that, we change
compiletestself-tests to reject running against stage 0rustcunless explicitly allowed withbuild.compiletest-allow-stage0=true.build.compiletest-allow-stage0is a proper bootstrap config option in favor of the ad-hocCOMPILETEST_FORCE_STAGE0env var. This means that:./x test src/tools/compiletest --stage=0is not allowed, unlessbuild.compiletest-allow-stage0=trueis set. In this scenario,compiletestself-tests should be expected to fail unless the stage 0rustcas provided is like codegen_cranelift where it's actually built from in-treerustcsources../x test src/tools/compiletest --stage=0to./x test src/tools/compiletest --stage=1, and move it topr-check-2. Yes, this involves building the stage 1 compiler, butpr-check-2already has to build stage 1 compiler to test stage 1 library crates.compiletestis only intended to support one target spec JSON format, namely the one corresponding to the in-treerustc.compiletest-use-stage0-libtestUX optimization where changingcompiler/tree should still not require rebuildingcompiletestas long asbuild.compiletest-use-stage0-libtest=true, as that should remain orthogonal. This is completely unlike my previous attempt at Considercompiletesta stagedToolStdtool #144563 that tries to do a way more invasive change which would cause the rebuild problem.Best reviewed commit-by-commit.
r? @Kobzol