| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Address libunwind.a inconsistency issues in the bootstrap program
We noticed when building rustc multiple time in a roll, some files will not be consistent across the build despite the fact that they are built from same source under the same environment. This patch addresses the inconsistency issue we found on libunwind.a, by sorting the order of the files passed to the linker.
|
|
|
|
It is essentially a RustcPrivate tool, so it should be treated as such using the new `RustcPrivateCompilers` infra.
|
|
|
|
|
|
|
|
Consolidate staging for `rustc_private` tools
This PR continues bootstrap refactoring, this time by consolidating staging for `Mode::ToolRustc` tools. This refactoring was in the critical path of refactoring `test`/`dist`/`clippy`/`doc` steps, and getting rid of the rmeta/rlib sysroot copy, because tools are pervasive and they are being used for a lot of things in bootstrap.
The main idea is to explicitly model the fact that a stage N `Mode::ToolRustc` tool always works with two different compilers:
- Stage N-1 rustc (`build_compiler`) builds stage N rustc (`target_compiler`)
- Rlib artifacts from stage N rustc are copied to the sysroot of stage N-1 rustc
- Stage N-1 rustc builds the (stage N) tool itself, the tool links to the rlib artifacts of the stage N rustc
Before, the code often used `compiler`, which meant sometimes the build compiler, sometimes the target compiler, and sometimes neither (looking at you, `download-rustc`). This is especially annoying when you get to a situation where you have an install step that invokes a dist step that invokes a tool build step, where *some* compiler is being propagated through, without it being clear what does that compiler represent. This refactoring hopefully makes that clearer and more explicit. It also gets rid of a few `builder.ensure(Rustc(...))` calls within bootstrap, which is always nice.
`Rustdoc` needs to be handled a bit specially, because it acts as a compiler itself, I documented that in the changes.
It wasn't practical to do these refactorings in multiple PRs, so I did it all in one PR. The meat of the change is 9ee6d1c1ed112c3dcfb5684b33772b136df0dca3.
I tested manually that `x build rustdoc` and `x build miri` still works even with `download-rustc`, although I cannot promise any extra support for `download-rustc`, IMO we will just have to reimplement it from scratch in a different way.
As usually, I did some drive-by refactorings to bootstrap, trying to document and clarify things, add more step metadata and tests.
Since these changes broke Cargo, which was incorrectly using `Mode::ToolRustc`, I also changed cargo to `ToolTarget` in this PR.
Best reviewed commit-by-commit (note that I renamed `link_compiler` to `target_compiler`, in accordance to the rest of bootstrap, in the last commit).
r? `@jieyouxu`
try-job: x86_64-gnu-aux
try-job: x86_64-msvc-ext1
|
|
|
|
|
|
|
|
|
|
Testing ui-fulldeps in "stage 1" actually uses the stage 0 compiler, so that
test programs can link against stage 1 rustc crates.
Unfortunately, using the stage 0 compiler causes problems when compiletest
tries to obtain target information from the compiler, but the output format has
changed since the last bootstrap beta bump.
We can work around this by also providing compiletest with a stage 1 compiler,
and having it use that compiler to query for target information.
|
|
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/rust#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````
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
functions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
