Skip to content

./x.py test --stage 0 src/libcore compiles rustc #52176

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

Closed
RalfJung opened this issue Jul 9, 2018 · 4 comments
Closed

./x.py test --stage 0 src/libcore compiles rustc #52176

RalfJung opened this issue Jul 9, 2018 · 4 comments

Comments

@RalfJung
Copy link
Member

RalfJung commented Jul 9, 2018

When I do ./x.py build --stage 0 src/libcore, it just builds libcore with the bootstrap compiler and is done fairly quickly. However, if I want to run the tests using ./x.py test --stage 0 src/libcore, it goes ahead and compiles a stage 0 rustc and does a stage 1 std build and tests that! This takes forever. Seems like stage handling is off when using test?

@RalfJung
Copy link
Member Author

RalfJung commented Jul 9, 2018

Stage 0 tests generally do not seem to work very well -- I can into #52186 also I am also getting errors like

error[E0460]: found possibly newer version of crate `std` which `rand` depends on
  --> libcore/../libcore/tests/lib.rs:50:1
   |
50 | extern crate rand;
   | ^^^^^^^^^^^^^^^^^^
   |
   = note: perhaps that crate needs to be recompiled?
   = note: the following crate versions were found:
           crate `std`: /home/r/src/rust/rustc.2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-acba8e5dff5ff58f.rlib
           crate `std`: /home/r/src/rust/rustc.2/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libstd-acba8e5dff5ff58f.rlib
           crate `std`: /home/r/src/rust/rustc.2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-acba8e5dff5ff58f.so
           crate `std`: /home/r/src/rust/rustc.2/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libstd-acba8e5dff5ff58f.so
           crate `rand`: /home/r/src/rust/rustc.2/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librand-467b6a656af26977.rlib

that I "fix" by manually deleting some files from stage0-std.

My theory for why it builds the compiler is that it needs rustdoc to generate the doctest binary, and it does not want to / cannot use a "bootstrap rustdoc" so it builds rustc and then rustdoc and then uses that.

So maybe x.py should just outright refuse to run tests in stage 0, if it does not work anyway. However, that would make it even more important to fix #52174 so that one can run tests without rebuilding the compiler :)

@RalfJung
Copy link
Member Author

Actually, testing stage 0 would be really nice to have: Running test --stage 1 src/libcore will use the compiler (built with the new libcore) to build stage 1 libcore; if one screwed up real bad when working on libcore, that compiler will not work -- and not being able to run the test suite doesn't make debugging simpler.

@RalfJung
Copy link
Member Author

The compiler build definitely happens from the self.rustdoc(compiler.host) call in builder::cargo.

On the plus side, I found out that adding --no-doc makes a stage 0 test actually work without compiling rustc. :) So that's good to know.

However, stage 0 tests with doctests still seem pretty much broken. Can these even reasonably work without having a "bootstrap rustdoc"?

@RalfJung
Copy link
Member Author

I am going to close this in favor of #52186.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant