As more and more of the span refiner's functionality has been pulled out into
separate early passes, it has finally reached the point where we can remove the
rest of the old `SpansRefiner` code, and replace it with a single
modestly-sized function.
Edition 2024: Make `!` fall back to `!`
This PR changes never type fallback to be `!` (the never type itself) in the next, 2024, edition.
This makes the never type's behavior more intuitive (in 2024 edition) and is the first step of the path to stabilize it.
r? `@compiler-errors`
Rollup of 6 pull requests
Successful merges:
- #115974 (Split core's PanicInfo and std's PanicInfo)
- #125659 (Remove usage of `isize` in example)
- #125669 (CI: Update riscv64gc-linux job to Ubuntu 22.04, rename to riscv64gc-gnu)
- #125684 (Account for existing bindings when suggesting `pin!()`)
- #126055 (Expand list of trait implementers in E0277 when calling rustc with --verbose)
- #126174 (Migrate `tests/run-make/prefer-dylib` to `rmake.rs`)
r? `@ghost`
`@rustbot` modify labels: rollup
Account for existing bindings when suggesting `pin!()`
When we encounter a situation where we'd suggest `pin!()`, we now account for that expression existing as part of an assignment and provide an appropriate suggestion:
```
error[E0599]: no method named `poll` found for type parameter `F` in the current scope
--> $DIR/pin-needed-to-poll-3.rs:19:28
|
LL | impl<F> Future for FutureWrapper<F>
| - method `poll` not found for this type parameter
...
LL | let res = self.fut.poll(cx);
| ^^^^ method not found in `F`
|
help: consider pinning the expression
|
LL ~ let mut pinned = std::pin::pin!(self.fut);
LL ~ let res = pinned.as_mut().poll(cx);
|
```
Fix#125661.
Split core's PanicInfo and std's PanicInfo
`PanicInfo` is used in two ways:
1. As argument to the `#[panic_handler]` in `no_std` context.
2. As argument to the [panic hook](https://doc.rust-lang.org/stable/std/panic/fn.set_hook.html) in `std` context.
In situation 1, the `PanicInfo` always has a *message* (of type `fmt::Arguments`), but never a *payload* (of type `&dyn Any`).
In situation 2, the `PanicInfo` always has a *payload* (which is often a `String`), but not always a *message*.
Having these as the same type is annoying. It means we can't add `.message()` to the first one without also finding a way to properly support it on the second one. (Which is what https://github.com/rust-lang/rust/issues/66745 is blocked on.)
It also means that, because the implementation is in `core`, the implementation cannot make use of the `String` type (which doesn't exist in `core`): 0692db1a90/library/core/src/panic/panic_info.rs (L171-L172)
This also means that we cannot easily add a useful method like `PanicInfo::payload_as_str() -> Option<&str>` that works for both `&'static str` and `String` payloads.
I don't see any good reasons for these to be the same type, other than historical reasons.
---
This PR is makes 1 and 2 separate types. To try to avoid breaking existing code and reduce churn, the first one is still named `core::panic::PanicInfo`, and `std::panic::PanicInfo` is a new (deprecated) alias to `PanicHookInfo`. The crater run showed this as a viable option, since people write `core::` when defining a `#[panic_handler]` (because they're in `no_std`) and `std::` when writing a panic hook (since then they're definitely using `std`). On top of that, many definitions of a panic hook don't specify a type at all: they are written as a closure with an inferred argument type.
(Based on some thoughts I was having here: https://github.com/rust-lang/rust/pull/115561#issuecomment-1725830032)
---
For the release notes:
> We have renamed `std::panic::PanicInfo` to `std::panic::PanicHookInfo`. The old name will continue to work as an alias, but will result in a deprecation warning starting in Rust 1.82.0.
>
> `core::panic::PanicInfo` will remain unchanged, however, as this is now a *different type*.
>
> The reason is that these types have different roles: `std::panic::PanicHookInfo` is the argument to the [panic hook](https://doc.rust-lang.org/stable/std/panic/fn.set_hook.html) in std context (where panics can have an arbitrary payload), while `core::panic::PanicInfo` is the argument to the [`#[panic_handler]`](https://doc.rust-lang.org/nomicon/panic-handler.html) in no_std context (where panics always carry a formatted *message*). Separating these types allows us to add more useful methods to these types, such as `std::panic::PanicHookInfo::payload_as_str()` and `core::panic::PanicInfo::message()`.
Print `token::Interpolated` with token stream pretty printing.
This is a step towards removing `token::Interpolated` (#124141). It unavoidably changes the output of the `stringify!` macro, generally for the better.
r? `@petrochenkov`
run-make-support: add wrapper for `fs` operations
Suggested by #125728.
The point of this wrapper is to stop silent fails caused by forgetting to `unwrap` `fs` functions. However, functions like `fs::read` which return something and get stored in a variable should cause a failure on their own if they are not unwrapped (as the `Result` will be stored in the variable, and something will be done on that `Result` that should have been done to its contents). Is it still pertinent to wrap `fs::read_to_string`, `fs::metadata` and so on?
Closes: https://github.com/rust-lang/rust/issues/125728
try-job: x86_64-msvc
try-job: i686-mingw
Rollup of 5 pull requests
Successful merges:
- #126186 (Migrate `run-make/multiple-emits` to `rmake.rs`)
- #126236 (Delegation: fix ICE on recursive delegation)
- #126254 (Remove ignore-cross-compile directive from ui/macros/proc_macro)
- #126258 (Do not define opaque types when selecting impls)
- #126265 (interpret: ensure we check bool/char for validity when they are used in a cast)
r? `@ghost`
`@rustbot` modify labels: rollup
interpret: ensure we check bool/char for validity when they are used in a cast
In general, `Scalar::to_bits` is a bit dangerous as it bypasses all type information. We should usually prefer matching on the type and acting according to that. So I also refactored `unary_op` handling of integers to do that. The remaining `to_bits` uses are operations that just fundamentally don't care about the sign (and only work on integers).
invalid_char_cast.rs is the key new test, the others already passed before this PR.
r? `@oli-obk`
Remove ignore-cross-compile directive from ui/macros/proc_macro
All the other proc-macro tests don't have this, presumably this was forgotten when the restriction got lifted as it does test just fine
r? `@pietroalbini`
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
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
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`
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`
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
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 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.
rustdoc: Add support for --remap-path-prefix
Adds `--remap-path-prefix` as an unstable option. This is implemented to mimic the behavior of `rustc`'s `--remap-path-prefix`.
This flag similarly takes in two paths, a prefix to replace and a replacement string.
This is useful for build tools (e.g. Buck) other than cargo that can run doc tests.
cc: `@dtolnay`
Rollup of 4 pull requests
Successful merges:
- #126172 (Weekly `cargo update`)
- #126176 (rustdoc-search: use lowercase, non-normalized name for type search)
- #126190 (Autolabel run-make tests, remind to update tracking issue)
- #126194 (Migrate more things to `WinError`)
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc-search: use lowercase, non-normalized name for type search
The type name ID map has underscores in its names, so the query element should have them, too.
Fixes#125993
