Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#152901 (Introduce a `#[diagnostic::on_unknown]` attribute)
- rust-lang/rust#155078 (Reject dangling attributes in where clauses)
- rust-lang/rust#154449 (Invert dependency between `rustc_errors` and `rustc_abi`.)
- rust-lang/rust#154646 (Add suggestion to `.to_owned()` used on `Cow` when borrowing)
- rust-lang/rust#154993 (compiletest: pass -Zunstable-options for unpretty and no-codegen paths)
- rust-lang/rust#155097 (Make `rustc_attr_parsing::SharedContext::emit_lint` take a `MultiSpan` instead of a `Span`)
Add suggestion to `.to_owned()` used on `Cow` when borrowing
fixesrust-lang/rust#144792
supersedes rust-lang/rust#144925 with the review comments addressed
the tests suggested from @Kivooeo from https://github.com/rust-lang/rust/pull/144925#discussion_r2252703007 didn't work entirely, because these tests failed due to error `[E0308]` mismatched types, which actually already provides a suggestion, that actually makes the code compile:
```
$ cargo check
error[E0308]: mismatched types
--> src/main.rs:3:5
|
1 | fn test_cow_suggestion() -> String {
| ------ expected `std::string::String` because of return type
2 | let os_string = std::ffi::OsString::from("test");
3 | os_string.to_string_lossy().to_owned()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `String`, found `Cow<'_, str>`
|
= note: expected struct `std::string::String`
found enum `std::borrow::Cow<'_, str>`
help: try using a conversion method
|
3 | os_string.to_string_lossy().to_owned().to_string()
| ++++++++++++
```
now this suggestion is of course not good or efficient code, but via clippy with `-Wclippy::nursery` lint group you can actually get to the correct code, so i don't think this is too much of an issue:
<details>
<summary>the clippy suggestions</summary>
```
$ cargo clippy -- -Wclippy::nursery
warning: this `to_owned` call clones the `Cow<'_, str>` itself and does not cause its contents to become owned
--> src/main.rs:3:5
|
3 | os_string.to_string_lossy().to_owned().to_string()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/beta/index.html#suspicious_to_owned
= note: `#[warn(clippy::suspicious_to_owned)]` on by default
help: depending on intent, either make the `Cow` an `Owned` variant
|
3 | os_string.to_string_lossy().into_owned().to_string()
| ++
help: or clone the `Cow` itself
|
3 - os_string.to_string_lossy().to_owned().to_string()
3 + os_string.to_string_lossy().clone().to_string()
|
$ # apply first suggestion
$ cargo c -- -Wclippy::nursery
warning: redundant clone
--> src/main.rs:3:45
|
3 | os_string.to_string_lossy().into_owned().to_string()
| ^^^^^^^^^^^^ help: remove this
|
note: this value is dropped without further use
--> src/main.rs:3:5
|
3 | os_string.to_string_lossy().into_owned().to_string()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= help: for further information visit https://rust-lang.github.io/rust-clippy/beta/index.html#redundant_clone
= note: `-W clippy::redundant-clone` implied by `-W clippy::nursery`
= help: to override `-W clippy::nursery` add `#[allow(clippy::redundant_clone)]`
```
</details>
the actual error that we are looking for is error `[E0515]`, cannot return value referencing local variable, which was only present in the original issue due to automatic type inference assuming you want to return a cloned `Cow<'_, str>`, which is of course not possible. this is why i took the original test functions and turned them into closures, where it's less obvious that it's trying to return the wrong type.
r? davidtwco
(because you reviewed the last attempt)
(also, let me know if i should squash this down to one commit and add myself as the co-contributor)
Reject dangling attributes in where clauses
Report `attribute without where predicates` for trailing outer attributes in where clauses.
Closesrust-lang/rust#155073 .
Introduce a `#[diagnostic::on_unknown]` attribute
This PR introduces a `#[diagnostic::on_unknown]` attribute that allows crate authors to customize the error messages emitted by unresolved imports. The main usecase for this is using this attribute as part of a proc macro that expects a certain external module structure to exist or certain dependencies to be there.
For me personally the motivating use-case are several derives in diesel, that expect to refer to a `tabe` module. That is done either implicitly (via the name of the type with the derive) or explicitly by the user. This attribute would allow us to improve the error message in both cases:
* For the implicit case we could explicity call out our assumptions (turning the name into lower case, adding an `s` in the end)
+ point to the explicit variant as alternative
* For the explicit variant we would add additional notes to tell the user why this is happening and what they should look for to fix the problem (be more explicit about certain diesel specific assumptions of the module structure)
I assume that similar use-cases exist for other proc-macros as well, therefore I decided to put in the work implementing this new attribute. I would also assume that this is likely not useful for std-lib internal usage.
related rust-lang/rust#152900 and rust-lang/rust#128674
delegation: fix unelided lifetime ICE, refactoring of GenericArgPosition
This PR does two things:
- First it restores `lower_generic_args_of_path` as it was before rust-lang/rust#151864, as it turns out we should use `GenericArgPosition::Type` for generic args lowering for signature inheritance, as it will not cause lifetime inference and then ICEs during child args lowering,
- Next it refactors `GenericArgPosition` enum replacing `Value` and `MethodCall` with `Call(IsMethodCall)`, as the only place where we created `Value` or `MethodCall` variants was in `check_generic_arg_count_for_call`, where it was a match over `is_method_call`. Not sure it is needed, but seems cleaner to me.
Fixesrust-lang/rust#154178, part of rust-lang/rust#118212.
r? @petrochenkov
Fix `pattern_from_macro_note` for bit-or expr
This is a continuation of issue https://github.com/rust-lang/rust/issues/99380 (and pr https://github.com/rust-lang/rust/pull/124488) but covers bit-or pattern.
Essentially a `pat1 | pat2`, or any bit-or pattern used in a `$e:expr` was not firing the `.pattern_from_macro_note` diagnostic bc `ast::Expr::is_approximately_pattern()` did not cover bit-or.
The cover for bit-or is only added in `lower_expr_within_pat()`, otherwise doing it in `is_approximately_pattern()` would result in the suggestion `if (i + 2) = 2 => if let (i + 2) = 2` from `suggest_pattern_match_with_let()` (which is the only other place `ast::Expr::is_approximately_pattern()` is used from what i see).
resolves https://github.com/rust-lang/rust/issues/99380
refs https://github.com/rust-lang/rust/pull/124488
Fix ICE when combining #[eii] with #[core::contracts::ensures]
Fixesrust-lang/rust#153745
Builtin attribute macros like #[eii] generate AST items programmatically without collected tokens. When another attribute macro was present on the same item, the compiler would panic in TokenStream::from_ast() trying to tokenize the generated items during subsequent attribute expansion.
Generate fake token streams (via pretty-print and re-parse) for Item and ForeignItem nodes that lack collected tokens, following the existing pattern used for Crate and out-of-line modules.
Restrict EII declarations to functions at lowering time
We tighten EII declaration resolution so that `lower_path_simple_eii` only accepts function‑like items (`Fn, AssocFn, Ctor(_, Fn)`) as valid EII targets. If name resolution points at something else (like a const with the same name), we now emit a direct error (“`externally implementable items must refer to a function`”) at the declaration site, which prevents bad `DefIds` from ever reaching `compare_eii_function_types` and turning into an ICE
this is more robust and root-cause oriented fix to rust-lang/rust#152337 issue and an alternate of my more simple PR rust-lang/rust#152365
test included
Always exhaustively match on typing mode
r? @lcnr
Unimplements Eq/PartialEq for TypingMode, adds TypingModeEqWrapper for the few cases where we need it (mainly in the query system), and adds a new rustc internal lint to detect cases where we non-exhaustively match on typing mode.
Moreover, dereference `ty_layout.align` for `#[rustc_dump_layout(align)]`
to render `align: Align($N bytes)` instead of `align: AbiAlign { abi: Align($N bytes) }`
which contains the same amount of information but it more concise and legible.
This PR introduces a `#[diagnostic::on_unknown_item]` attribute that
allows crate authors to customize the error messages emitted by
unresolved imports. The main usecase for this is using this attribute as
part of a proc macro that expects a certain external module structure to
exist or certain dependencies to be there.
For me personally the motivating use-case are several derives in diesel,
that expect to refer to a `tabe` module. That is done either
implicitly (via the name of the type with the derive) or explicitly by
the user. This attribute would allow us to improve the error message in
both cases:
* For the implicit case we could explicity call out our
assumptions (turning the name into lower case, adding an `s` in the end)
+ point to the explicit variant as alternative
* For the explicit variant we would add additional notes to tell the
user why this is happening and what they should look for to fix the
problem (be more explicit about certain diesel specific assumptions of
the module structure)
I assume that similar use-cases exist for other proc-macros as well,
therefore I decided to put in the work implementing this new attribute.
I would also assume that this is likely not useful for std-lib internal
usage.
Deny `#[global_allocator]` + `#[thread_local]`
This forbids using `#[thread_local]` on `static` items that are also `#[global_allocator]`s.
Fixesrust-lang/rust#85517.
hwaddress: automatically add `-Ctarget-feature=+tagged-globals`
Note that since HWAddressSanitizer is/should be a target modifier, we do not have to worry about whether this LLVM target feature changes the ABI.
Fixes: rust-lang/rust#148185
Fix linker error by resolving regions for main return type obligations
This PR fix linker error by resolving regions for main return type obligations as discussed in https://github.com/rust-lang/rust/issues/148421
Added a final check . Now the compiler double-checks the lifetimes for main right away. If they don't work it stops and gives the user a clean compiler error instead of a linker crash.
Fixes https://github.com/rust-lang/rust/issues/148421.
delegation: fix cycles during delayed lowering
This PR forces lowering of delayed owners after `hir_crate_items`, as some diagnostics use `hir_crate_items` which results in query cycle which is then hangs calling `def_path_str` again and again. Fixesrust-lang/rust#154169. Part of rust-lang/rust#118212.
r? @petrochenkov
Fix pattern types rendering in rustdoc
Closesrust-lang/rust#150889 .
`core` was rendering local pattern-type impls through `clean_ty`, which formatted `rustc_hir::TyPat` with derived Debug, while inlined docs go through `clean_middle_ty` and get the pretty-printed `rustc_middle::ty::Pattern`.
Lower local HIR pattern types before formatting so both paths share the same canonical pattern printer and stop exposing `TyPat { ... }` in implementors.
#### Current result:
<img width="1133" height="738" alt="截屏2026-04-07 22 47 26" src="https://github.com/user-attachments/assets/bb5f8942-30b1-400a-a0a0-f581da5bb59f" />
core::sync: rename `Exclusive` to `SyncView` and make improvements
This PR implements the renaming of `core::sync::Exclusive` to `SyncView` as decided in rust-lang/rust#98407. To preserve the ability to search for the old name, it adds `Exclusive` as a `doc_alias`.
It also makes the following additional changes:
- Converting the `get_mut` method to being an instance of `AsMut::as_mut`. In the process, it makes both the new `impl AsMut` and the existing `impl AsRef` `const`, and it also renames `get_pin_mut` to `as_pin_mut` for consistency. This direction follows a suggestion from rust-lang/rust#98407.
- Adding an `as_pin` method that can only be used when the wrapped type implements `Sync`, to complete the square of access methods.
- Making as many of the existing `impl`s `const` as possible; this involved making the existing `impl Default` no longer derived.
- Adding `impl`s for `AsyncFnOnce`, `AsyncFnMut`, and `AsyncFn`, akin to the existing `impls` for `FnOnce`, `FnMut`, and `Fn`.
It does not yet do the following, which may be desirable:
- Fixing/improving the documentation to address the concern pointed out in rust-lang/rust#146245.
It previously did the following, but this was removed after discussion:
- Adding an `impl` for (`const`) `Iterator`, which felt in line with the existing `impl`s for `Future` and `Coroutine`.
usamoi