compiletest should be built with the stage2 compiler not the stage0 compiler #59264
Labels
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Comments
|
Doing things this way (using stage2) would also have ensured that #57709 was detected early, and never made it into a release. |
|
We would prefer to build tools such as compiletest with the bootstrap compiler because stage1, stage2 compilers take a long time to build. I think largely we just can't at this point support building with multiple compilers -- i.e., the bootstrap compiler should be the same one we use in tree. We just don't have the CI budget and resources to test and support multiple versions of the compiler for crates using unstable features. As such, I think the only resolution here will be to close this... cc @rust-lang/infra and @alexcrichton though since this is somewhat of a policy type decision (and we don't have a firm policy AFAIK). |
|
As a matter of policy, we do need such rebuild-bootstrapping to continue to be supported to some extent, even if it's only a "tier-2" use case. That is, fixing these sort of issues reactively is still better than nothing. |
|
Is conditional compilation based on the compiler version possible in Rust today? That could be an alternative solution, instead of always using stage2. The language here is a bit technical and I couldn't figure it out. |
|
I guess for now, I could hack that sort of logic into the Debian build script manually in an ad-hoc way - applying the patch vs not, based on the stage0 compiler version. |
jonas-schievink
added
the
T-bootstrap
|
I think if we wanted to solve this issue the best way to do it would be to:
That way |
I think in general a policy of unstable tools/dependencies having the requirement of being in-tree deps instead of beta is reasonable, yeah. I can try to make a patch that makes compiletest (and if there are any other such tools) do this sometime this week. |
|
Same issue with 1.40.0 again, when using itself as stage0: CC @cuviper AFAICT you do not have a patch that fixes this on Fedora either. |
Centril
added a commit
to Centril/rust
that referenced
this issue
Jan 9, 2020
…-Simulacrum Build compiletest with in-tree libtest This updates compiletest to build in `Mode::ToolStd`, using the locally-built crates for `std` and especially `test`. This way we're immune to unstable differences in the bootstrap compiler crates, whether that's a prior-release stage0 or a current release local rebuild. Fixes rust-lang#59264. As a minor cleanup, this also removes the unused `llvm_tools` flag.
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this issue
Jan 10, 2020
…-Simulacrum Build compiletest with in-tree libtest This updates compiletest to build in `Mode::ToolStd`, using the locally-built crates for `std` and especially `test`. This way we're immune to unstable differences in the bootstrap compiler crates, whether that's a prior-release stage0 or a current release local rebuild. Fixes rust-lang#59264. As a minor cleanup, this also removes the unused `llvm_tools` flag.
Centril
added a commit
to Centril/rust
that referenced
this issue
Jan 10, 2020
…-Simulacrum Build compiletest with in-tree libtest This updates compiletest to build in `Mode::ToolStd`, using the locally-built crates for `std` and especially `test`. This way we're immune to unstable differences in the bootstrap compiler crates, whether that's a prior-release stage0 or a current release local rebuild. Fixes rust-lang#59264. As a minor cleanup, this also removes the unused `llvm_tools` flag.
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this issue
Jan 10, 2020
…-Simulacrum Build compiletest with in-tree libtest This updates compiletest to build in `Mode::ToolStd`, using the locally-built crates for `std` and especially `test`. This way we're immune to unstable differences in the bootstrap compiler crates, whether that's a prior-release stage0 or a current release local rebuild. Fixes rust-lang#59264. As a minor cleanup, this also removes the unused `llvm_tools` flag.
jyn514
added a commit
to jyn514/rust
that referenced
this issue
May 22, 2022
This statically prevents issues like rust-lang#59264, where tools can only be built with the in-tree compiler and not beta.
jyn514
added a commit
to jyn514/rust
that referenced
this issue
May 25, 2022
Using language features occasionally causes issues when using nightly to bootstrap, rather than beta. See rust-lang#59264 for additional context.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
May 26, 2022
…lacrum Only allow `compiletest` to use `feature(test)`, not any other feature Using language features occasionally causes issues when using nightly to bootstrap, rather than beta. See rust-lang#59264 for additional context.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See #57709. Unfortunately the "fix" to that bug breaks the build when building using 1.31.0 and you have to unapply the patch to make it work against 1.31.0.
e.g. from https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=amd64&ver=1.32.0%2Bdfsg1-1&stamp=1548672224&raw=0 :
The problem here is that if stage0 is 1.31.0 then the patch MUST be unapplied, if stage0 is 1.32.0 then the patch MUST be applied. Obviously we can't do both at once.
However in both Debian and Fedora we occasionally use either the current or the previous version of rustc to build a given version of rustc, and both of these versions should work.
cc @cuviper
The text was updated successfully, but these errors were encountered: