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`)
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.
Post-attribute ports cleanup pt. 1
r? @jdonszelmann
This cleans up some checks I could find were for non-parsed attributes, and works towards removing BUILTIN_ATTRIBUTES
All commits do one thing and every commit passes tests, so best reviewed commit by commit
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.
Add `-Zsanitize=kernel-hwaddress`
The Linux kernel has a config option called `CONFIG_KASAN_SW_TAGS` that enables `-fsanitize=kernel-hwaddress`. This is not supported by Rust.
One slightly awkward detail is that `#[sanitize(address = "off")]` applies to both `-Zsanitize=address` and `-Zsanitize=kernel-address`. Probably it was done this way because both are the same LLVM pass. I replicated this logic here for hwaddress, but it might be undesirable.
Note that `#[sanitize(kernel_hwaddress = "off")]` could be supported as an annotation on statics, but since it's also missing for `#[sanitize(hwaddress = "off")]`, I did not add it.
MCP: https://github.com/rust-lang/compiler-team/issues/975
Tracking issue: https://github.com/rust-lang/rust/issues/154171
cc @rcvalle @maurer @ojeda
Introduce #[diagnostic::on_move(message)]
cc rust-lang/rust#149862
This is a first proposal. I have deliberately kept it simpler than `diagnostic::on_unimplemented`.
Few questions/remarks:
- Do I need to move the OnMoveDirective logic into a dedicated module perhaps ? let's say into compiler/rustc_borrowck/src/diagnostics/on_move.rs
- No problems to depend on crates like `rustc_ast` from the borrowck ?
- Notes are not supported yet. While message and label are very static , in the sense that they are emitted in the same way from the same place in the borrowck, it is not the case for the notes. It would make the code more complex. But, I can add support for notes if it does make sense.
Suggestions are welcomed !
Reimplement const closures
Tracking issue: rust-lang/rust#106003
Best reviewed commit-by-commit
The old solver can't handle `for<'a> |x: &'a()| ()` closures in const contexts, but that feature is unstable itself, so we can just leave it to the next solver to handle.
We need a lot more tests, we're testing the bare minimum of success and failure paths right now.
r? @fee1-dead
This might be helpful for smart pointers to explains why they aren't Copy
and what to do instead or just to let the user know that .clone() is very
cheap and can be called without a performance penalty.
stop marking `deref_patterns` as an incomplete feature
This PR removes the `incomplete_feature` warning for `deref_patterns`. The reason given for this in the tracking issue (rust-lang/rust#87121) was
> Per policy, the `incomplete_feature` is supposed to stay on until the feature has an accepted RFC. We're slowly working on writing up that RFC so it'll take some more time unfortunately.
>
> I don't know of any compiler crashes it causes today. The feature should be pretty usable.
However, I could not find any evidence of such a policy. The [lint documentation](https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#incomplete-features) for `incomplete_features` also only mentions features that are more likely to cause errors.
There are also many other features without an RFC that are not considered incomplete, e.g. `macro_metavar_expr_concat`, `negative_impls` or `yeet_expr`.
The feature does not cause any known ICEs either.
The concrete motivation is to use this feature to replace `box_patterns` in the compiler and pave the way towards removing that legacy feature.
Gate #![reexport_test_harness_main] properly
Address the FIXME
Removed from `issue-43106-gating-of-builtin-attrs.rs` since that is for stable attributes only.
This would be a breaking change, search of github shows it is mostly but not always used with `#![test_runner]` which is already gated correctly.
Details:
https://github.com/rust-lang/rust/issues/50297
Feel free to close this issue if you think it is not worth addressing the FIXME...
Tweak some of our internal `#[rustc_*]` TEST attributes
I think I might be the one who's used the internal TEST attrs `#[rustc_{dump_predicates,object_lifetime_default,outlives,variance}]` the most in recent times, I might even be the only one. As such I've noticed some recent-ish issues that haven't been fixed so far and which keep bothering me. Moreover I have a longstanding urge to rename several of these attributes which I couldn't contain anymore.
[`#[rustc_*]` TEST attributes](https://rustc-dev-guide.rust-lang.org/compiler-debugging.html#rustc_-test-attributes) are internal attributes that basically allow you to dump the output of specific queries for use in UI tests or for debugging purposes.
1. When some of these attributes were ported over to the new parsing API, their targets were unnecessarily restricted. I've kept encountering these incorrect "attribute cannot be used" errors all the while HIR analysis happily & correctly dumped the requested data below it. I've now relaxed their targets.
2. Since we now have target checking for the internal attributes I figured that it's unhelpful if we still intentionally crashed on invalid targets, so I've got rid of that.
3. I've always been annoyed that most of these (very old) attributes don't contain the word `dump` in their name (rendering their purpose non-obvious) and that some of their names diverge quite a bit from the corresponding query name. I've now rectified that. The new names take longer to type but it's still absolutely acceptable imo.
---
I haven't renamed all of the TEST attributes to follow the `rustc_dump_` scheme since that's quite tedious. If it's okay with you I'd like to postpone that (e.g., `rustc_{def_path,hidden_type…,layout,regions,symbol_name}`).
I've noticed that the parsers for TEST attrs are spread across `rustc_dump.rs`, `rustc_internal.rs` & `test_attrs.rs` which is a bit confusing. Since the new names are prefixed with `rustc_dump_` I've moved their parsers into `rustc_dump.rs` but of course they are still TEST attrs. IIRC, `test_attrs.rs` also contains non-`rustc_`-TEST attrs, so we can't just merge these two files. I guess that'll sort itself out in the future when I tackle the other internal TEST attrs.
r\? Jana || Jonathan
Parse `impl` restrictions
This PR implements the parsing logic for `impl` restrictions (e.g., `pub impl(crate) trait Foo {}`) as proposed in [RFC 3323](https://rust-lang.github.io/rfcs/3323-restrictions.html).
As the first step of the RFC implementation, this PR focuses strictly on the parsing phase. The new syntax is guarded by the `#![feature(impl_restriction)]` feature gate.
This implementation basically follows the pattern used in rust-lang/rust#141754.
r? @jhpratt
Mark Rousskov