Bootstrap command refactoring: improve debuggability (step 5)
Continuation of https://github.com/rust-lang/rust/pull/127321.
This PR improves the debuggability of command execution, by improving the output logged when a command fails (it now includes the exact location where the command was created and where it was executed), and also by adding a "drop bomb", which will panic if a command was created, but not executed (which is probably a bug).
Here is how the output of a failed command looks like:
```
Command "git" "foo" "[bar]" (failure_mode=Exit, stdout_mode=Capture, stderr_mode=Capture) did not execute successfully.
Expected success, got exit status: 1
Created at: src/core/build_steps/compile.rs:1699:9
Executed at: src/core/build_steps/compile.rs:1699:58
STDOUT ----
STDERR ----
git: 'foo' is not a git command. See 'git --help'.
```
And this is what is printed if you forget to execute a command:
```
thread 'main' panicked at /projects/personal/rust/rust/src/tools/build_helper/src/drop_bomb/mod.rs:42:13:
command constructed at `src/core/build_steps/compile.rs:1699:9` was dropped without being executed: `git`
```
Best reviewed commit by commit.
Tracking issue: https://github.com/rust-lang/rust/issues/126819
r? `@onur-ozkan`
Fix incorrect NDEBUG handling in LLVM bindings
We currently compile our LLVM bindings using `-DNDEBUG` if debuginfo for LLVM is disabled. However, `NDEBUG` doesn't have any relation to debuginfo, it controls whether assertions are enabled.
Split the LLVM_NDEBUG environment variable into two, so that assertions and debuginfo are controlled independently.
After this change, `LLVMRustDIBuilderInsertDeclareAtEnd` triggers an assertion failure on LLVM 19 due to an incorrect cast. Fix it by removing the unused return value entirely.
r? `@cuviper`
Rollup of 11 pull requests
Successful merges:
- #126502 (Ignore allocation bytes in some mir-opt tests)
- #126922 (add lint for inline asm labels that look like binary)
- #127209 (Added the `xop` target-feature and the `xop_target_feature` feature gate)
- #127310 (Fix import suggestion ice)
- #127338 (Migrate `extra-filename-with-temp-outputs` and `issue-85019-moved-src-dir` `run-make` tests to rmake)
- #127381 (Migrate `issue-83045`, `rustc-macro-dep-files` and `env-dep-info` `run-make` tests to rmake)
- #127535 (Fire unsafe_code lint on unsafe extern blocks)
- #127619 (Suggest using precise capturing for hidden type that captures region)
- #127631 (Remove `fully_normalize`)
- #127632 (Implement `precise_capturing` support for rustdoc)
- #127660 (Rename the internal `const_strlen` to just `strlen`)
r? `@ghost`
`@rustbot` modify labels: rollup
Implement `precise_capturing` support for rustdoc
Implements rustdoc (+json) support for local (i.e. non-cross-crate-inlined) RPITs with `use<...>` precise capturing syntax.
Tests kinda suck. They're really hard to write 😰
r? `@fmease` or re-roll if you're too busy!
also cc `@aDotInTheVoid` for the json side
Tracking:
* https://github.com/rust-lang/rust/issues/127228#issuecomment-2201443216 (not fully fixed for cross-crate-inlined opaques)
* https://github.com/rust-lang/rust/issues/123432
Migrate `extra-filename-with-temp-outputs` and `issue-85019-moved-src-dir` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Please try:
try-job: armhf-gnu
// try-job: test-various // already tried
try-job: x86_64-msvc
try-job: aarch64-apple
Ensure floats are returned losslessly by the Rust ABI on 32-bit x86
Solves #115567 for the (default) `"Rust"` ABI. When compiling for 32-bit x86, this PR changes the `"Rust"` ABI to return floats indirectly instead of in x87 registers (with the exception of single `f32`s, which this PR returns in general purpose registers as they are small enough to fit in one). No change is made to the `"C"` ABI as that ABI requires x87 register usage and therefore will need a different solution.
We currently compile our LLVM bindings using `-DNDEBUG` if
debuginfo for LLVM is disabled. However, `NDEBUG` doesn't have
any relation to debuginfo, it controls whether assertions are
enabled.
Rename the environment variable to `LLVM_ASSERTIONS` and drive
it using the `llvm_assertions` option. Also drop the explicit
`debug(false)` call, as cc already sets this up using the
cargo `DEBUG` environment variable.
The code for running tests uses a custom command machinery because it streams the output of the command. We thus need to mark the command as executed in a dry run, to avoid a drop bomb panic.
Update dist-riscv64-linux to binutils 2.40
binutils 2.40 is required by LLVM 19, as older versions do not know about the zmmul extension.
I've had to backport some patches to glibc and gcc as well, as they don't build with binutils 2.40. Alternatively, we could also switch to glibc 2.35 and gcc 10 (I think). I figured we'd want to avoid the glibc version change, but if that's fine for riscv I can go with that instead.
r? `````@cuviper`````
try-job: dist-riscv64-linux
Use rustc-stable-hash in the compiler
Following https://github.com/rust-lang/compiler-team/issues/755 and the release of the crate on crates.io, let's now use it in the compiler and remove the old implementation.
cc `@michaelwoerister`
r? ghost
compiletest: Better error message for bad `normalize-*` headers
Follow-up to #126777.
Example of the new error message in context:
```text
---- [ui] tests/ui/rfcs/rfc-2632-const-trait-impl/effects/minicore.rs stdout ----
thread '[ui] tests/ui/rfcs/rfc-2632-const-trait-impl/effects/minicore.rs' panicked at src/tools/compiletest/src/header.rs:1001:13:
couldn't parse custom normalization rule: `normalize-stderr-test ".*note: .*\n\n" -> ""`
help: expected syntax is: `normalize-stderr-test: "REGEX" -> "REPLACEMENT"`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
binutils 2.40 is required by LLVM 19, as older versions do not
know about the zmmull extension.
I've had to backport some patches to glibc and gcc as well,
as they don't build with binutils 2.40. Alternatively, we could
also switch to glibc 2.35 and gcc 12 (I think). I figured we'd
want to avoid the glibc version change, but if that's fine for
riscv I can go with that instead.
Require a colon in `//@ normalize-*:` test headers
The previous parser for `//@ normalize-*` headers (before #126370) was so lax that it did not require `:` after the header name. As a result, the test suite contained a mix of with-colon and without-colon normalize headers, both numbering in the hundreds.
This PR updates the without-colon headers to add a colon (matching the style used by other headers), and then updates the parser to make the colon mandatory.
(Because the normalization parser only runs *after* the header system identifies a normalize header, this will detect and issue an error for relevant headers that lack the colon.)
Addresses one of the points of #126372.
Implement simple, unstable lint to suggest turning closure-of-async-block into async-closure
We want to eventually suggest people to turn `|| async {}` to `async || {}`. This begins doing that. It's a pretty rudimentary lint, but I wanted to get something down so I wouldn't lose the code.
Tracking:
* #62290
Migrate `issue-83112-incr-test-moved-file`, `type-mismatch-same-crate-name` and `issue-109934-lto-debuginfo` `run-make` tests to rmake or ui
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
I have noticed that the new UI test `debuginfo-lto-alloc` is outputting artifacts that aren't getting cleaned up because of its `-C incremental`. That might be the justification needed to keep it as a run-make test?
Try it on:
// try-job: test-various // previously passed
try-job: armhf-gnu
try-job: aarch64-apple
try-job: x86_64-msvc
Fix local download of Docker caches from CI
https://github.com/rust-lang/rust/pull/127312 broke local downloads of Docker caches from CI, when you wanted to build a Docker image locally. This PR fixes that.
r? `@nikic`
(Can you please check if the cache works for you with this PR?)
Fix running bootstrap tests with a local Rust toolchain as the stage0
When configuring a local Rust toolchain as the stage0 (with `build.rustc` and `build.cargo` in `config.toml`) we noticed there were test failures (both on the Python and the Rust side) due to bootstrap not being able to find rustc and Cargo.
This was due to those two `config.toml` settings not being propagated in the tests. This PR fixes the issue by ensuring rustc and cargo are always configured in tests, using the parent bootstrap's `initial_rustc` and `initial_cargo`.
try-job: x86_64-msvc
Fixes https://github.com/rust-lang/rust/issues/105766
Migrate `extern-flag-pathless`, `silly-file-names`, `metadata-dep-info`, `cdylib-fewer-symbols` and `symbols-include-type-name` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
`cdylib-fewer-symbols` demands a Windows try-job. (Almost guaranteed to fail, but 7 years is a long time)
try-job: x86_64-gnu-distcheck
try-job: x86_64-msvc
try-job: aarch64-apple
`Config::src` already contains the top-level path, so we don't need to
add git overhead just to reach this path.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
