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`)
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
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
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.
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#154912 (Remove `BuiltinLintDiag`)
- rust-lang/rust#154598 (test `#[naked]` with `#[link_section = "..."]` on windows)
- rust-lang/rust#154719 (Hexagon inline asm: add reg_pair, vreg, vreg_pair, and qreg register classes)
- rust-lang/rust#154057 (Parenthesize block-like expressions in index base of pretty printer)
- rust-lang/rust#154893 (make `expected_literal` positive)
- rust-lang/rust#155002 (Clarify that `core::range` ranges do not have special syntax)
Use fine grained component-wise span tracking in use trees
This often produces nicer spans and even doesn't need a Span field anymore (not that I expect the unused field to affect any perf, but still neat).
Remove `Clone` impl for `StableHashingContext`.
`HashStable::hash_stable` takes a `&mut Hcx`. In contrast, `ToStableHashKey::to_stable_hash_key` takes a `&Hcx`. But there are some places where the latter calls the former, and due to the mismatch a `clone` call is required to get a mutable `StableHashingContext`.
This commit changes `to_stable_hash_key` to instead take a `&mut Hcx`. This eliminates the mismatch, the need for the clones, and the need for the `Clone` impls.
r? @fee1-dead
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#154376 (Remove more BuiltinLintDiag variants - part 4)
- rust-lang/rust#154731 (llvm: Fix array ABI test to not check equality implementation)
- rust-lang/rust#127534 (feat(core): impl Step for NonZero<u*>)
- rust-lang/rust#154703 (Fix trailing comma in lifetime suggestion for empty angle brackets)
- rust-lang/rust#154776 (Fix ICE in read_discriminant for enums with non-contiguous discriminants)
Fix trailing comma in lifetime suggestion for empty angle brackets
Fixesrust-lang/rust#154600
When suggesting a lifetime parameter (e.g., `'a`) for a type like `Foo<>` (empty angle brackets), the compiler was incorrectly producing `Foo<'a, >` with a trailing comma.
## Root Cause
The `has_existing_params` check used `segment.args` to determine if generic parameters exist. However, for empty angle brackets (`<>`), the parser doesn't create any `args`, so `has_existing_params` was `false` — even though the angle brackets themselves exist.
This caused the suggestion logic to skip the comma+space suffix (`"'a, "`), but the insert position was still inside the angle brackets, leading to `Foo<'a, >` instead of `Foo<'a>`.
## Fix
Replace the `segment.args`-based check with a source text inspection using `span_to_snippet`. The new logic:
1. Finds the `<` character in the source text
2. Extracts the content between `<` and `>`
3. Checks if that content is non-empty (after trimming whitespace)
This correctly identifies `<>` as having no existing parameters, avoiding the trailing comma.
## Test
Added `tests/ui/lifetimes/E0106-trailing-comma-in-lifetime-suggestion.rs` covering the specific case of empty angle brackets with lifetime suggestions.
Port lint attributes to attribute parser
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152369)*
Tracking issue: rust-lang/rust#131229
Ports `#[allow]`, `#[deny]`, `#[expect]`, `#[forbid]`, and `#[warn]` to being parsed attrs
I tried my best to make this PR as small as possible, it was difficult. I hope it isn't too difficult to review
r? @JonathanBrouwer
r? @jdonszelmann
`HashStable::hash_stable` takes a `&mut Hcx`. In contrast,
`ToStableHashKey::to_stable_hash_key` takes a `&Hcx`. But there are
some places where the latter calls the former, and due to the mismatch a
`clone` call is required to get a mutable `StableHashingContext`.
This commit changes `to_stable_hash_key` to instead take a `&mut Hcx`.
This eliminates the mismatch, the need for the clones, and the need for
the `Clone` impls.
Avoid creating async return opaques for foreign async fns
Fixes https://github.com/rust-lang/rust/issues/146754
Previously, def collection created the desugared async return opaque for foreign `async fn` items, but AST lowering won't lower that opaque for foreign items. That left a `DefId` without a corresponding HIR owner, which later caused an ICE during analysis.
opaque_generic_const_args -> generic_const_args
This is part of a larger rework/plan of how to move forward with GCA. Please comment here, or message/ping me or @BoxyUwU if you have questions about the future of oGCA/GCA!
For ease of review, the first commit is renaming, and the second commit is removing the opaque parts.
fyi @camelid
r? @BoxyUwU
Attributes containing rustc
r? @petrochenkov
I noticed that attributes *containing* the word rustc as a segment also error with a message referring to "starting with rustc". The first commit shows this going wrong by re-exporting `#[test]`, a built-in macro, from a module called rustc.
The 2nd commit addresses this by changing the diagnostic. However, given the wording I wonder if the real solution shouldn't be to allow attributes containing a `rustc` segment and only disallow them when they start. In other words, actually implement the behavior that the original diagnostic pointed out.
Add macro matcher for `guard` fragment specifier
Tracking issue #153104
This PR implements a new `guard` macro matcher to match `if-let` guards (specifically [`MatchArmGuard`](https://github.com/rust-lang/reference/blob/50a1075e879be75aeec436252c84eef0fad489f4/src/expressions/match-expr.md#match-guards)). In the upcoming PR, we can use this new matcher in the `matches!` and `assert_matches!` macros to support their use with `if-let` guards. (see #152313)
The original `Expr` used to represent a guard has been wrapped in a new `Guard` type, allowing us to carry the span information of the leading `if` keyword. However, it might be even better to include the `if` keyword in the `Guard` type as well? I've left a FIXME comment in the code.
Avoid prematurely choosing a glob import
Fixes rust-lang/rust#153842
Use the following without introducing trait to explain:
```rust
mod a {
pub use crate::x::y as x; // single import #1
}
mod b {
pub mod x {
pub mod y {}
}
}
use a::x; // single import #2
use b::*; // glob import #3
fn main() {}
```
In current implementation, when `#1` is first resolved, `crate::x` is temporarily taken from glob import `#3` as `crate::b::x`. This happens because `single_import_can_define_name` will see that `#2` cannot define `x` (because it depends on `#1` and `#1` is ignored) and then return `false`. Later, during finalization, `crate::x` in `#1` resolves through single import `#2` instead, which no longer matches the initially cached module `crate::b::x` and triggers the ICE.
I think the resolver should keep this unresolved because `#2` may still define `x` to avoid prematurely choosing a glob import.
r? petrochenkov
diagnostics: avoid ICE for undeclared generic parameter in impl
Avoid an ICE for:
struct A;
impl A<B> {}
The compiler no longer panics and can proceed to emit existing diagnostics.
Adds `tests/ui/missing/undeclared-generic-parameter.rs`.
Fixesrust-lang/rust#154165 and introduced by rust-lang/rust#152913
Avoid an ICE for:
struct A;
impl A<B> {}
The compiler no longer panics and can proceed to emit existing diagnostics.
Adds `tests/ui/missing/undeclared-generic-parameter.rs`.
Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com>
mejrs