Currently all core and std macros are automatically added to the prelude
via #[macro_use]. However a situation arose where we want to add a new macro
`assert_matches` but don't want to pull it into the standard prelude for
compatibility reasons. By explicitly exporting the macros found in the core and
std crates we get to decide on a per macro basis and can later add them via
the rust_20xx preludes.
The split between walk_pat and maybe_read_scrutinee has now become
redundant.
Due to this change, one testcase within the testsuite has become similar
enough to a known ICE to also break. I am leaving this as future work,
as it requires feature(type_alias_impl_trait)
```
error[E0308]: mismatched types
--> $DIR/macro-span-caller-replacement.rs:5:17
|
LL | s = format!("{arg}");
| ^^^^^^^^^^^^^^^^ expected `&str`, found `String`
...
LL | macro_with_format!();
| -------------------- in this macro invocation
|
= note: this error originates in the macro `format` which comes from the expansion of the macro `macro_with_format` (in Nightly builds, run with -Z macro-backtrace for more info)
```
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#147725 (Remove -Zoom=panic)
- rust-lang/rust#148294 (callconv: fix mips64 aggregate argument passing for C FFI)
- rust-lang/rust#148491 ( Correctly provide suggestions when encountering `async fn` with a `dyn Trait` return type)
- rust-lang/rust#149458 (Run clippy on cg_gcc in CI)
- rust-lang/rust#149679 (Restrict spe_acc to PowerPC SPE targets)
- rust-lang/rust#149781 (Don't suggest wrapping attr in unsafe if it may come from proc macro)
- rust-lang/rust#149795 (Use `let`...`else` instead of `match foo { ... _ => return };` and `if let ... else return` in std)
- rust-lang/rust#149816 (Make typo in field and name suggestions verbose)
- rust-lang/rust#149824 (Add a regression test for issue 145748)
- rust-lang/rust#149826 (compiletest: tidy up `adb_path`/`adb_test_dir` handling)
r? `@ghost`
`@rustbot` modify labels: rollup
Deduplicate higher-ranked lifetime capture errors in impl Trait
Previously, when an `impl Trait` captured multiple higher-ranked
lifetimes from an outer `impl Trait`, the compiler would emit a
separate error for each captured lifetime. This resulted in verbose
and confusing diagnostics, especially in edition 2024 where implicit
captures caused duplicate errors.
This commit introduces error accumulation that collects all capture
spans and lifetime declaration spans, then emits a single consolidated
diagnostic using MultiSpan. The new error shows all captured lifetimes
with visual indicators and lists all declarations in a single note.
r? `@estebank`
Fixes https://github.com/rust-lang/rust/issues/143022
```
error[E0277]: the trait bound `[[u16; 3]; 2]: Bar` is not satisfied
--> $DIR/issue-67185-2.rs:21:6
|
LL | impl Foo for FooImpl {}
| ^^^ the trait `Bar` is not implemented for `[[u16; 3]; 2]`
|
help: the following other types implement trait `Bar`
--> $DIR/issue-67185-2.rs:9:1
|
LL | impl Bar for [u16; 4] {}
| ^^^^^^^^^^^^^^^^^^^^^ `[u16; 4]`
LL | impl Bar for [[u16; 3]; 3] {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ `[[u16; 3]; 3]`
note: required by a bound in `Foo`
--> $DIR/issue-67185-2.rs:14:30
|
LL | trait Foo
| --- required by a bound in this trait
LL | where
LL | [<u8 as Baz>::Quaks; 2]: Bar,
| ^^^ required by this bound in `Foo`
```
```
error[E0277]: the trait bound `u32: Trait` is not satisfied
--> $DIR/trait_objects_fail.rs:26:9
|
LL | foo(&10_u32);
| ^^^^^^^ the trait `Trait` is not implemented for `u32`
|
help: the trait `Trait<12>` is not implemented for `u32`
but trait `Trait<2>` is implemented for it
--> $DIR/trait_objects_fail.rs:7:1
|
LL | impl Trait<2> for u32 {}
| ^^^^^^^^^^^^^^^^^^^^^
= note: required for the cast from `&u32` to `&dyn Trait`
```
Pointing at the `impl` definition that *could* apply given a different self type is particularly useful when it has a blanket self type, as it might not be obvious and is not trivially greppable:
```
error[E0277]: the trait bound `RawImpl<_>: Raw<_>` is not satisfied
--> $DIR/issue-62742.rs:4:5
|
LL | WrongImpl::foo(0i32);
| ^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Raw<_>` is not implemented for `RawImpl<_>`
but trait `Raw<[_]>` is implemented for it
--> $DIR/issue-62742.rs:29:1
|
LL | impl<T> Raw<[T]> for RawImpl<T> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: required by a bound in `SafeImpl`
--> $DIR/issue-62742.rs:33:35
|
LL | pub struct SafeImpl<T: ?Sized, A: Raw<T>>(PhantomData<(A, T)>);
| ^^^^^^ required by this bound in `SafeImpl`
```
Previously, when an `impl Trait` captured multiple higher-ranked
lifetimes from an outer `impl Trait`, the compiler would emit a
separate error for each captured lifetime. This resulted in verbose
and confusing diagnostics, especially in edition 2024 where implicit
captures caused duplicate errors.
This commit introduces error accumulation that collects all capture
spans and lifetime declaration spans, then emits a single consolidated
diagnostic using MultiSpan. The new error shows all captured lifetimes
with visual indicators and lists all declarations in a single note.
We'll still error due to the `opt_bad_ty` of `method_autoderef_steps`.
This slightly worsens the span of `infer_var.method()` which is now the
same as for `Box::new(infer_var).method()`.
Unlike `structurally_resolve_type`, `probe_op` does not check whether
the infcx is already tainted, so this results in 2 previously not emitted
errors.
When encountering an unmet trait bound, point at local type that doesn't implement the trait:
```
error[E0277]: the trait bound `Bar<T>: Foo` is not satisfied
--> $DIR/issue-64855.rs:9:19
|
LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ;
| ^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Foo` is not implemented for `Bar<T>`
--> $DIR/issue-64855.rs:9:1
|
LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ;
| ^^^^^^^^^^^^^^^^^
```
Use `splice` to avoid shifting the other items twice.
Put `extern crate std;` first so it's already resolved when we resolve `::std::prelude::rust_20XX`.
In order to expose edition dependent divergences in some tests in the test suite, add explicit `edition` annotations. Some of these tests might require additional work to *avoid* the divergences, as they might have been unintentional. These are not exhaustive changes, purely opportunistic while looking at something else.
Make obligation cause code suggestions verbose
```
error[E0277]: `()` is not a future
--> $DIR/unnecessary-await.rs:28:10
|
LL | e!().await;
| ^^^^^ `()` is not a future
|
= help: the trait `Future` is not implemented for `()`
= note: () must be a future or must implement `IntoFuture` to be awaited
= note: required for `()` to implement `IntoFuture`
help: remove the `.await`
|
LL - e!().await;
LL + e!();
|
```
```
error[E0277]: the trait bound `String: Copy` is not satisfied
--> $DIR/const-fn-in-vec.rs:1:47
|
LL | static _MAYBE_STRINGS: [Option<String>; 5] = [None; 5];
| ^^^^ the trait `Copy` is not implemented for `String`
|
= note: required for `Option<String>` to implement `Copy`
= note: the `Copy` trait is required because this value will be copied for each element of the array
help: create an inline `const` block
|
LL | static _MAYBE_STRINGS: [Option<String>; 5] = [const { None }; 5];
| +++++++ +
```
Part of rust-lang/rust#141973
```
error[E0277]: `()` is not a future
--> $DIR/unnecessary-await.rs:28:10
|
LL | e!().await;
| ^^^^^ `()` is not a future
|
= help: the trait `Future` is not implemented for `()`
= note: () must be a future or must implement `IntoFuture` to be awaited
= note: required for `()` to implement `IntoFuture`
help: remove the `.await`
|
LL - e!().await;
LL + e!();
|
```
```
error[E0277]: the trait bound `String: Copy` is not satisfied
--> $DIR/const-fn-in-vec.rs:1:47
|
LL | static _MAYBE_STRINGS: [Option<String>; 5] = [None; 5];
| ^^^^ the trait `Copy` is not implemented for `String`
|
= note: required for `Option<String>` to implement `Copy`
= note: the `Copy` trait is required because this value will be copied for each element of the array
help: create an inline `const` block
|
LL | static _MAYBE_STRINGS: [Option<String>; 5] = [const { None }; 5];
| +++++++ +
```
Add a new `mismatched-lifetime-syntaxes` lint
The lang-team [discussed this](https://hackmd.io/nf4ZUYd7Rp6rq-1svJZSaQ) and I attempted to [summarize](https://github.com/rust-lang/rust/pull/120808#issuecomment-2701863833) their decision. The summary-of-the-summary is:
- Using two different kinds of syntax for elided lifetimes is confusing. In rare cases, it may even [lead to unsound code](https://github.com/rust-lang/rust/issues/48686)! Some examples:
```rust
// Lint will warn about these
fn(v: ContainsLifetime) -> ContainsLifetime<'_>;
fn(&'static u8) -> &u8;
```
- Matching up references with no lifetime syntax, references with anonymous lifetime syntax, and paths with anonymous lifetime syntax is an exception to the simplest possible rule:
```rust
// Lint will not warn about these
fn(&u8) -> &'_ u8;
fn(&'_ u8) -> &u8;
fn(&u8) -> ContainsLifetime<'_>;
```
- Having a lint for consistent syntax of elided lifetimes will make the [future goal](https://github.com/rust-lang/rust/issues/91639) of warning-by-default for paths participating in elision much simpler.
---
This new lint attempts to accomplish the goal of enforcing consistent syntax. In the process, it supersedes and replaces the existing `elided-named-lifetimes` lint, which means it starts out life as warn-by-default.
Run wfcheck in one big loop instead of per module
Maybe we can merge this big loop in the future with the `par_hir_body_owners` call below and run typeck only on items that didn't fail wfcheck. For now let's just see if perf likes it, as it by itself should be beneficial to parallel rustc
This adds an `iter!` macro that can be used to create movable
generators.
This also adds a yield_expr feature so the `yield` keyword can be used
within iter! macro bodies. This was needed because several unstable
features each need `yield` expressions, so this allows us to stabilize
them separately from any individual feature.
Co-authored-by: Oli Scherer <github35764891676564198441@oli-obk.de>
Co-authored-by: Jieyou Xu <jieyouxu@outlook.com>
Co-authored-by: Travis Cross <tc@traviscross.com>
