Windows: Don't link std (and run-make) against advapi32, except on win7
Std no longer depends on any functionality provided by advapi32, so we can remove it from the list of external libraries we link against. Except, the win7 targets do still rely on advapi32-provided functionality. This PR therefore moves linking against it to only occur on win7 targets, so that no new uses of it slip in without being noticed.
bootstrap: Fix stack printing when a step cycle is detected
When bootstrap detects a step dependency cycle (which represents a bootstrap bug), it is supposed to print out the contents of the step stack as part of its panic message.
However, while investigating #138205 it was found that bootstrap was actually printing out several copies of `Any { .. }`, because that is the Debug implementation for `dyn Any`. This is sadly not very helpful.
This PR fixes that problem by introducing a `trait AnyDebug: Any + Debug` that delegates to the underlying type's Debug implementation, while still allowing downcasting via Any.
---
The fixed behaviour can be verified manually (and is tested automatically) via a new dummy command, `./x run cyclic-step`:
```
$ x run cyclic-step
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.02s
thread 'main' panicked at src/bootstrap/src/core/builder/mod.rs:1521:17:
Cycle in build detected when adding CyclicStep { n: 0 }
CyclicStep { n: 0 }
CyclicStep { n: 1 }
CyclicStep { n: 2 }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:00:00
```
add `tool::CargoClippy` and `tool::Cargofmt` binary to target sysroot
When running `x build clippy`, we expect `stage1-tool-bin/cargo-clippy` and `stage2/bin/cargo-clippy` to be the same, but they aren't. This happens because `tool::CargoClippy` doesn't place its binary in the `stage2` directory. As a result, `stage1-tool-bin/cargo-clippy` comes from `tool::CargoClippy`, while `stage2/bin/cargo-clippy` comes from `tool::Cargo`. Same applies for `tool::Cargofmt`.
This PR fixes the issue by adding `tool::CargoClippy` and ``tool::Cargofmt`` binaries to the expected sysroot and makes sure both directories share the same binary.
To test this, run `x build --stage 2 compiler clippy rustfmt`, link the stage2 sysroot with rustup, and then call `cargo +stage2 fmt` and `cargo +stage2 clippy` on any rust project (it wouldn't work without this PR).
skip `compile::Std` and `compile::Rustc` on `forced_compiler`
Fixes https://github.com/rust-lang/rust/issues/138220
Set `download-rustc = true/false` and run `x test tests/ui/meta/no_std-extern-libc.rs --force-rerun` to debug it.
Rollup of 5 pull requests
Successful merges:
- #136642 (Put the alloc unit tests in a separate alloctests package)
- #137528 (Windows: Fix error in `fs::rename` on Windows 1607)
- #137685 (self-contained linker: conservatively default to `-znostart-stop-gc` on x64 linux)
- #137757 (On long spans, trim the middle of them to make them fit in the terminal width)
- #138189 (Mention `env` and `option_env` macros in `std::env::var` docs)
r? `@ghost`
`@rustbot` modify labels: rollup
Put the alloc unit tests in a separate alloctests package
Same rationale as https://github.com/rust-lang/rust/pull/135937. This PR has some extra complexity though as a decent amount of tests are testing internal implementation details rather than the public api. As such I opted to include the modules containing the types under test using `#[path]` into the alloctests package. This means that those modules still need `#[cfg(test)]`, but the rest of liballoc no longer need it.
Prevent `rmake.rs` from using unstable features, and fix 3 run-make tests that currently do
Addresses (mostly) #137532.
Follow-up to #137373.
### Summary
- Fix 3 run-make tests that currently use unstable features:
1. `tests/run-make/issue-107495-archive-permissions/rmake.rs` uses `#![feature(rustc_private)]` for `libc` on `unix`, but `run_make_support` already exports `libc`, so just use that.
2. `tests/run-make/cross-lang-lto/rmake.rs` uses `#![feature(path_file_prefix)]` for convenience, replaced with similar filename prefix logic.
3. `tests/run-make/broken-pipe-no-ice/rmake.rs` uses `#![feature(anonymous_pipe)]` for anonymous pipes. This is more complicated[^race-condition], and I decided to temporarily introduce a dependency on [`os_pipe`] before std's `anonymous_pipe` library feature is stabilized[^pipe-stab]. I left a FIXME tracked by #137532 to make the switch once `anonymous_pipe` stabilizes and reaches beta.
- Use `RUSTC_BOOTSTRAP=-1` when building `rmake.rs` to have the stage 0 rustc reject any unstable features used in `rmake.rs`.
- The requirement that `rmake.rs` may not use any unstable features is now documented in rustc-dev-guide.
- This PR does not impose `RUSTC_BOOTSTRAP=-1` when building `run-make-support`, but I suppose we could.
r? `@Kobzol`
try-job: x86_64-msvc-1
try-job: x86_64-mingw-1
[`os_pipe`]: https://github.com/oconnor663/os_pipe.rs
[^race-condition]: We can't just try to spawn `rustc` and immediate close the stderr handle because of race condition, as there's no guarantee `rustc` will not try to print to stderr before the handle gets closed.
[^pipe-stab]: In-progress stabilization PR over at https://github.com/rust-lang/rust/pull/135822.
By naming them in `[workspace.lints.rust]` in the top-level
`Cargo.toml`, and then making all `compiler/` crates inherit them with
`[lints] workspace = true`. (I omitted `rustc_codegen_{cranelift,gcc}`,
because they're a bit different.)
The advantages of this over the current approach:
- It uses a standard Cargo feature, rather than special handling in
bootstrap. So, easier to understand, and less likely to get
accidentally broken in the future.
- It works for proc macro crates.
It's a shame it doesn't work for rustc-specific lints, as the comments
explain.
use target compiler on llvm-bitcode-linker
The build compiler is already resolved inside the `ToolBuild` step, so we should pass only the target compilers for `Mode::ToolRustc` tools.
Fixes https://github.com/rust-lang/rust/issues/138123
r? ghost
try-job: dist-powerpc64le-linux
The build compiler is already resolved inside the `ToolBuild` step,
so we should pass only the target compilers for `Mode::ToolRustc` tools.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Reduce the noise of bootstrap changelog warnings in --dry-run mode
Presently x.py displays "There have been changes to x.py since you last updated:" note only once when run normally, but on every invocation when run with `--dry-run`.
The disparity is not exactly intentonal, but just a historical accident.
It was made to be printed once in https://github.com/rust-lang/rust/pull/117815 via storing `.last-warned-change-id` on disk in `{config.out}/bootstrap` (i.e. `build/bootstrap`) directory.
But that didn't quite work for `--dry-run`, since `{config.out}/bootsrap` points to `build/tmp-dry-run/bootstrap` which *isn't* created in dry-run mode, so file creation fails.
This got fixed in https://github.com/rust-lang/rust/pull/118789 and now `--dry-run` does not save `.last-warned-change-id` at all. (Nor does it read it, since it cannot know to read from non-dry-run location)
This PR simply stops displaying the changelog altogether in --dry-run mode.
<details>
<summary>previous attempt (outdated)</summary>
This PR takes a different approach, and instead of not-writing the stamp in `--dry-run` mode it instead tries harder to yes-write it, and, specifically, creates `build/tmp-dry-run/bootstrap` directory to do so. If neccessary (i.e. if there are changes newer than the `change-id` stamp of config.toml to warn about).
Note that `build/tmp-dry-run/` was *already* being created, so making an extra `boostrap` sub-folder should not meaningfully pollute the build dir.
</details>
(Apologies for the, perhaps, excessively wordy PR, I'm new to this)
bootstrap and compiletest: Use `size_of_val` from the prelude instead of imported
Use `std::mem::size_of_val` from the prelude instead of importing or qualifying it.
This function was added to all preludes in Rust 1.80.
r? ``@jieyouxu``
handle forced compiler and revert #137476
Fixes https://github.com/rust-lang/rust/issues/138004
I would appreciate it if we could measure CI pipelines with the current changes to see if this reduces recent CI overhead. cc `@rust-lang/infra`
try-job: dist-powerpc64le-linux
Various coretests improvements
The first commit is not yet strictly necessary as directly testing libcore works though useless work, but will be necessary once https://github.com/rust-lang/rust/pull/136642 migrates the liballoc tests into a separate package. The second commit fixes https://github.com/rust-lang/rust/issues/137478 and ensures that coretests actually gets tested on all CI job. The third commit fixes an error that didn't get caught because coretests doesn't run on the wasm32 CI job.
Add `dist::Gcc` build step
This PR adds a `dist:Gcc` bootstrap step to distribute a prebuilt `libgccjit.so` from CI on x64 Linux.
With primed sccache, the build takes ~4 minutes on CI, and produces a 50 MiB archive.
I want to land this before adding something akin to `[gcc] download-ci-gcc = true`, to already have the artifacts available on CI, to make it easier to setup the download merge-base logic.
r? ``@ghost``
Compile run-make-support and run-make tests with the bootstrap compiler
It does not seem necessary to have to recompile run-make-support on changes to the local compiler/stdlib. This PR simplifies the implementation of a few tools, then switches rms to stage0 and also makes the handling of environment variables in run-make tests simpler.
Best reviewed commit-by-commit. I can split it into multiple PRs if you want.
Also tested that `COMPILETEST_FORCE_STAGE0=1 ./x test tests/run-make --stage 0` still works. Incredibly, it looks like it even passes more tests than on `master` 😆
r? ``@jieyouxu``
do not build additional stage on compiler paths
When calling `x build compiler (or rustc) --stage N` bootstrap builds stage N+1 compiler, which is clearly not what we requested. This doesn't happen when running `x build --stage N` without explicitly targeting the compiler.
The changes applied fix this issue.
r? ghost
When calling `x build compiler (or rustc) --stage N` bootstrap builds stage N+1 compiler,
which is clearly not what we requested. This doesn't happen when running `x build --stage N`
without explicitly targeting the compiler.
The changes applied fix this issue.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
