Cleanup of `#[derive(Diagnostic)]` attribute parsers
This PR does a lot of refactoring on the implementation of `#[derive(Diagnostic)]`. It should have no observable effect other than error messages for incorrect usage of the attributes. In general, I think the error messages got better.
This PR can be reviewed commit by commit, each commit passes the tests.
- [Convert parse_nested_meta to parse_args_with for #[diagnostic]](https://github.com/rust-lang/rust/pull/151657/changes/9e61014a8a0bb1f1d7911511c303a7ae2a9c2a7d)
Start parsing `#[diagnostic]` using `syn`'s `parse_args_with` function instead of `parse_nested_meta`. This improves error messages and prepares for the new syntax needed for https://github.com/rust-lang/rust/issues/151366 which cannot be parsed using `parse_args_with`.
- [Convert parse_nested_meta to parse_args_with for #[subdiagnostic]](https://github.com/rust-lang/rust/pull/151657/changes/5d21a21695d56b74ea249f269ee10195251008b7)
Same as above but for `#[subdiagnostic]`
- [Remove unused no_span option](https://github.com/rust-lang/rust/pull/151657/changes/0bf3f5d51cb853884240792818d81e70daec6ab7)
Removes the `no_span` option of `#[suggestion]`, which there were no tests for and which seems to have been unused. If needed again in the future, this can be re-added pretty easily, but I find that unlikely.
- [Remove HasFieldMap trait in favour of passing FieldMap directly](https://github.com/rust-lang/rust/pull/151657/changes/2e8347abf4147d2bffe4d7989a21b17ae04cdb57)
Removes the `HasFieldMap` trait, because I don't really see the point of having a trait "has a field map" if we can just pass the fieldmap itself instead.
r? @Kivooeo
(Thanks for reviewing my PRs so far :3)
fix(parser): Disallow CR in frontmatter
T-lang came back on the stabilization PR (rust-lang/rust#148051) asking for CR to be disallowed
to leave room for all stray CRs to be rejected in the future.
At that point, the test can remain but the implementation can be
removed.
If that plan does not go through, we'll need to re-evaluate
- whether this is more lint-like and should defer to the calling tool
that is managing the frontmatter
- how much Rust should treat the frontmatter as Rust and apply the same
grammar restrictions of "no stray CR" (like raw string literals)
Part of rust-lang/rust#136889
Rollup of 12 pull requests
Successful merges:
- rust-lang/rust#150474 (Tidy: detect ui tests subdirectory changes so `tests/ui/README.md` stays in sync)
- rust-lang/rust#150572 (Improve move error diagnostic for `AsyncFn` closures)
- rust-lang/rust#151596 (Fix -Zmir-enable-passes to detect unregistered enum names in declare_passes macro)
- rust-lang/rust#151802 (Make `QueryDispatcher::Qcx` an associated type)
- rust-lang/rust#149110 (Implement `cast_slice` for raw pointer types)
- rust-lang/rust#151559 ([rustdoc] Add a marker to tell users that there are hidden (deprecated) items in the search results)
- rust-lang/rust#151665 (Fix contrast ratio for `Since` element in rustdoc dark theme)
- rust-lang/rust#151785 (Stabilize feature(push_mut))
- rust-lang/rust#151798 (Update `askama` to `0.15.3`)
- rust-lang/rust#151800 (Subscribe myself to translation diagnostics)
- rust-lang/rust#151804 (Document, sort, and tweak spellcheck entries in `typos.toml`)
- rust-lang/rust#151805 (Fix grammar in `env::current_exe()#Security`)
[rustdoc] Add a marker to tell users that there are hidden (deprecated) items in the search results
Someone on mastodon rightfully pointed out that having a visual indication that some search results were hidden would be a good idea if the "hide deprecated items" setting is enabled. In particular if no results are displayed.
It looks like this:
<img width="861" height="228" alt="Screenshot From 2026-01-24 00-26-33" src="https://github.com/user-attachments/assets/93aeef11-a550-47dc-9c78-219ea4fd822c" />
r? @lolbinarycat
Make `QueryDispatcher::Qcx` an associated type
There's no reason to think that a query dispatcher/vtable would support multiple query-context types, and this simplifies some generic signature boilerplate.
---
- This is the planned change that was mentioned in https://github.com/rust-lang/rust/pull/151777#issuecomment-3810715635.
r? nnethercote
Improve move error diagnostic for `AsyncFn` closures
When an async closure captures a variable by move but is constrained to `AsyncFn` or `AsyncFnMut`, the error message now explains that the closure kind is the issue and points to the trait bound, similar to the existing diagnostic for `Fn`/`FnMut` closures.
**Before:**
```
error[E0507]: cannot move out of `foos` which is behind a shared reference
--> src/lib.rs:12:20
|
11 | async fn foo(foos: &mut [&mut Foo]) -> Result<(), ()> {
| ---- move occurs because `foos` has type...
12 | in_transaction(async || -> Result<(), ()> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ `foos` is moved here
13 | for foo in foos {
| ---- variable moved due to use in coroutine
```
**After:**
```
error[E0507]: cannot move out of `y`, a captured variable in an `AsyncFn` closure
--> src/lib.rs:9:10
|
LL | let y = vec![format!("World")];
| - captured outer variable
LL | call(async || {
| ^^^^^^^^ captured by this `AsyncFn` closure
...
help: `AsyncFn` and `AsyncFnMut` closures require captured values to be able
to be consumed multiple times, but `AsyncFnOnce` closures may consume
them only once
--> src/lib.rs:5:27
|
LL | fn call<F>(_: F) where F: AsyncFn() {}
| ^^^^^^^^^
```
Fixesrust-lang/rust#150174
Tidy: detect ui tests subdirectory changes so `tests/ui/README.md` stays in sync
close: rust-lang/rust#150399
There's an issue where `tests/ui/README.md` isn't updated whenever the ui subdirectory changes.
I've added subdirectory change detection to tidy ~~added a new mention to `triage.toml` to notify `tests/ui/README.md` to also be updated~~.
r? @Urgau
clean up checks for constant promotion of integer division/remainder operations
I found the old logic with matches on `Option`s returned by other matches to be kind of complicated, so I rewrote it with `let` chains. There should be no change in behavior.
Implement `set_output_kind` for Emscripten linker
This makes cdylibs compile to working Emscripten dynamic libraries without passing extra RUSTFLAGS. This was previously approved as rust-lang/rust#98358 but there were CI failures that I never got around to fixing.
cc @workingjubilee
Borrowck: Simplify SCC annotation computation, placeholder rewriting
This change backports some changes from the now abandoned rust-lang/rust#142623.
Notably, it simplifies the `PlaceholderReachability` `enum` by replacing the case when no placeholders were reached with a standard `Option::None`.
It also rewrites the API for `scc::Annotations` to be update-mut rather than a more Functional programming style. This showed some slight performance impact in early tests of the PR and definitely makes the implementation simpler.
This probably wants a perf run just for good measure.
r? @lcnr
compiler-builtins: Remove the no-f16-f128 feature
This option was used to gate `f16` and `f128` when support across backends and targets was inconsistent. We now have the rustc builtin cfg `target_has_reliable{f16,f128}` which has taken over this usecase. Remove no-f16-f128 since it is now unused and redundant.
Do not suggest `derive` if there is already an impl
This PR fixes an issue where the compiler would suggest adding `#[derive(Trait)]` even if the struct or enum already implements that trait manually.
Fixes [#146515](https://github.com/rust-lang/rust/issues/146515)
T-lang came back on the stabilization PR asking for CR to be disallowed
to leave room for all stray CRs to be rejected in the future.
At that point, the test can remain but the implementation can be
removed.
If that plan does not go through, we'll need to re-evaluate
- whether this is more lint-like and should defer to the calling tool
that is managing the frontmatter
- how much Rust should treat the frontmatter as Rust and apply the same
grammar restrictions of "no stray CR" (like raw string literals)
