run-make: arm command wrappers with drop bombs
This PR is one in a series of cleanups to run-make tests and the run-make-support library.
### Summary
It's easy to forget to actually executed constructed command wrappers, e.g. `rustc().input("foo.rs")` but forget the `run()`, so to help catch these mistakes, we arm command wrappers with drop bombs on construction to force them to be executed by test code.
This PR also removes the `Deref`/`DerefMut` impl for our custom `Command` which derefs to `std::process::Command` because it can cause issues when trying to use a custom command:
```rs
htmldocck().arg().run()
```
fails to compile because the `arg()` is resolved to `std::process::Command::arg`, which returns `&mut std::process::Command` that doesn't have a `run()` command.
This PR also:
- Removes `env_var` on the `impl_common_helper` macro that was wrongly named and is a footgun (no users).
- Bumps the run-make-support library to version `0.1.0`.
- Adds a changelog to the support library.
### Details
Especially for command wrappers like `Rustc`, it's very easy to build up
a command invocation but forget to actually execute it, e.g. by using
`run()`. This commit adds "drop bombs" to command wrappers, which are
armed on command wrapper construction, and only defused if the command
is executed (through `run`, `run_fail`).
If the test writer forgets to execute the command, the drop bomb will
"explode" and panic with an error message. This is so that tests don't
silently pass with constructed-but-not-executed command wrappers.
This PR is best reviewed commit-by-commit.
try-job: x86_64-msvc
- Update all command wrappers and command construction helpers with
`#[track_caller]` where suitable to help the drop bomb panic message.
- Remove `Deref`/`DerefMut` for `Command` because it was causing issues
with resolving to `std::process::Command` in a method call chain.
Rollup of 5 pull requests
Successful merges:
- #125913 (Spruce up the diagnostics of some early lints)
- #126234 (Delegation: fix ICE on late diagnostics)
- #126253 (Simplify assert matchers in `run-make-support`)
- #126257 (Rename `needs-matching-clang` to `needs-force-clang-based-tests`)
- #126259 (reachable computation: clarify comments around consts)
r? `@ghost`
`@rustbot` modify labels: rollup
This is incorrectly named (it's actually `env_clear`), and is itself
a gigantic footgun: removing `TMPDIR` on Unix and `TMP`/`TEMP` on
Windows basically wrecks anything that relies on `std::env::temp_dir`
from functioning correctly. For example, this includes rustc's codegen.
Rename `needs-matching-clang` to `needs-force-clang-based-tests`
This header is much more restrictive than its old name would suggest. As a result, most of the tests that use it don't actually run in any CI jobs.
Mitigation for #126180, though at some point we still need to go back fix the affected tests to actually run.
Spruce up the diagnostics of some early lints
Implement the various "*(note to myself) in a follow-up PR we should turn parts of this message into a subdiagnostic (help msg or even struct sugg)*" drive-by comments I left in #124417 during my review.
For context, before #124417, only a few early lints touched/decorated/customized their diagnostic because the former API made it a bit awkward. Likely because of that, things that should've been subdiagnostics were just crammed into the primary message. This PR rectifies this.
Only compute `specializes` query if (min)specialization is enabled in the crate of the specializing impl
Fixes (after backport) https://github.com/rust-lang/rust/issues/125197
### What
https://github.com/rust-lang/rust/pull/122791 makes it so that inductive cycles are no longer hard errors. That means that when we are testing, for example, whether these impls overlap:
```rust
impl PartialEq<Self> for AnyId {
fn eq(&self, _: &Self) -> bool {
todo!()
}
}
impl<T: Identifier> PartialEq<T> for AnyId {
fn eq(&self, _: &T) -> bool {
todo!()
}
}
```
...given...
```rust
pub trait Identifier: Display + 'static {}
impl<T> Identifier for T where T: PartialEq + Display + 'static {}
```
Then we try to see if the second impl holds given `T = AnyId`. That requires `AnyId: Identifier`, which requires that `AnyId: PartialEq`, which is satisfied by these two impl candidates... The `PartialEq<T>` impl is a cycle, and we used to winnow it when we used to treat inductive cycles as errors.
However, now that we don't winnow it, this means that we *now* try calling `candidate_should_be_dropped_in_favor_of`, which tries to check whether one of the impls specializes the other: the `specializes` query. In that query, we currently bail early if the impl is local.
However, in a foreign crate, we try to compute if the two impls specialize each other by doing trait solving. This may itself lead to the same situation where we call `specializes`, which will lead to a query cycle.
### How does this fix the problem
We now record whether specialization is enabled in foreign crates, and extend this early-return behavior to foreign impls too. This means that we can only encounter these cycles if we truly have a specializing impl from a crate with specialization enabled.
-----
r? `@oli-obk` or `@lcnr`
CI: use a native `arm64` runner
Opening to test if we can use a native GitHub ARM runner instead of the self-hosted one.
The CI has finished [successfully](https://github.com/rust-lang/rust/actions/runs/9414573751/job/25933776975?pr=126113). It took 1h 29m, which is longer than the previous duration (~1h 10m). This is expected, since we currently use 8 cores on GitHub, rather than 14 cores which are configured for the self-hosted runner.
try-job: aarch64-gnu
Add `SingleUseConsts` mir-opt pass
The goal here is to make a pass that can be run in debug builds to simplify the common case of constants that are used just once -- that doesn't need SSA handling and avoids any potential downside of multi-use constants. In particular, to simplify the `if T::IS_ZST` pattern that's common in the standard library.
By also handling the case of constants that are *never* actually used this fully replaces the `ConstDebugInfo` pass, since it has all the information needed to do that naturally from the traversal it needs to do anyway.
This is roughly a wash on instructions on its own (a couple regressions, a few improvements https://github.com/rust-lang/rust/pull/125910#issuecomment-2144963361), with a bunch of size improvements. So I'd like to land it as its own PR, then do follow-ups to take more advantage of it (in the inliner, cg_ssa, etc).
r? `@saethlin`
Rollup of 9 pull requests
Successful merges:
- #126063 (Remove some unused crate dependencies.)
- #126115 (Fix ICE due to `unwrap` in `probe_for_name_many`)
- #126159 (ScalarInt: size mismatches are a bug, do not delay the panic)
- #126184 (interpret: do not ICE on padded non-pow2 SIMD vectors)
- #126191 (Fix `NonZero` doctest inconsistencies)
- #126211 (migrate tests/run-make/llvm-outputs to use rmake.rs)
- #126212 (fix: build on haiku)
- #126215 (Add explanatory note to async block type mismatch error)
- #126223 (run-make: add `run_in_tmpdir` self-test)
r? `@ghost`
`@rustbot` modify labels: rollup
Add Rust for Linux `auto` CI job
This PR adds an `auto` CI job that checks if Rust for Linux (RfL) still compiles with the latest version of the compiler and the standard library. If not, we should ideally ping the RfL ping group.
try-job: rfl
run-make: add `run_in_tmpdir` self-test
Add a basic sanity test for `run_in_tmpdir` to make sure that files (including read-only files) and directories created inside the "scratch" tmpdir are removed after the closure returns.
r? ghost (while i run a try job)
try-job: x86_64-msvc
Add explanatory note to async block type mismatch error
The async block type mismatch error might leave the user wondering as to why it occurred. The new note should give them the needed context.
Changes this diagnostic:
```
error[E0308]: mismatched types
--> src/main.rs:5:23
|
2 | let a = async { 1 };
| ----------- the expected `async` block
3 | let b = async { 2 };
| ----------- the found `async` block
4 |
5 | let bad = vec![a, b];
| ^ expected `async` block, found a different `async` block
|
= note: expected `async` block `{async block@src/main.rs:2:13: 2:24}`
found `async` block `{async block@src/main.rs:3:13: 3:24}`
```
to this:
```
error[E0308]: mismatched types
--> src/main.rs:5:23
|
2 | let a = async { 1 };
| ----------- the expected `async` block
3 | let b = async { 2 };
| ----------- the found `async` block
4 |
5 | let bad = vec![a, b];
| ^ expected `async` block, found a different `async` block
|
= note: expected `async` block `{async block@src/main.rs:2:13: 2:24}`
found `async` block `{async block@src/main.rs:3:13: 3:24}`
= note: no two async blocks, even if identical, have the same type
= help: consider pinning your async block and and casting it to a trait object
```
Fixes#125737
fix: build on haiku
## What does this PR do
The std is broken on haiku, this PR fixes it.
## To reproduce the issue
```sh
$ cargo +nightly --version
cargo 1.81.0-nightly (b1feb75d0 2024-06-07)
$ cargo new hello
$ cd hello
$ cargo +nightly check -Zbuild-std --target x86_64-unknown-haiku -q
error[E0433]: failed to resolve: use of undeclared crate or module `std`
--> ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/pal/unix/os.rs:468:13
|
468 | std::ptr::null_mut(),
| ^^^ use of undeclared crate or module `std`
|
help: consider importing one of these items
|
8 + use core::ptr;
|
8 + use crate::ptr;
|
help: if you import `ptr`, refer to it directly
|
468 - std::ptr::null_mut(),
468 + ptr::null_mut(),
|
error[E0433]: failed to resolve: use of undeclared crate or module `std`
--> ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/pal/unix/os.rs:470:13
|
470 | std::ptr::null_mut(),
| ^^^ use of undeclared crate or module `std`
|
help: consider importing one of these items
|
8 + use core::ptr;
```
migrate tests/run-make/llvm-outputs to use rmake.rs
part of #121876
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Fix `NonZero` doctest inconsistencies
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
`NonZero`'s doctests contain both `?` and `.unwrap()` with no obvious reason for the difference, so this changes all of them to `?`. Also removes an explicit `std::num::NonZero`.
Fix ICE due to `unwrap` in `probe_for_name_many`
Fixes#125876
Now `probe_for_name_many` bubbles up the error returned by `probe_op` instead of calling `unwrap` on it.
Mara Bos