rustdoc: sort stable items first
Finally tackling this again now that the search system refactor is done. The tests and the general approach were taken from the original PR.
Rollup of 14 pull requests
Successful merges:
- rust-lang/rust#152323 (Fix ICE in borrowck when recovering `fn_sig` for `-> _`)
- rust-lang/rust#152469 (Remove unused features)
- rust-lang/rust#152515 (Extract `DepKindVTable` constructors to their own module)
- rust-lang/rust#152555 (Port `#[rustc_diagnostic_item]` to the new attribute parsers)
- rust-lang/rust#152218 (Report unconstrained region in hidden types lazily)
- rust-lang/rust#152356 (Improve the `inline_fluent!` macro)
- rust-lang/rust#152392 (Fix ICE in supertrait_vtable_slot when supertrait has missing generics)
- rust-lang/rust#152407 (Add regression test for type_const with unit struct ctor under mGCA)
- rust-lang/rust#152440 (Fix typos and grammar in compiler and build documentation)
- rust-lang/rust#152536 (bootstrap: add explicit UTF-8 encoding to text-mode open() calls)
- rust-lang/rust#152554 (Remove `deprecated_safe` and its corresponding feature gate)
- rust-lang/rust#152556 (doc: move riscv64a23-unknown-linux-gnu to tier 2)
- rust-lang/rust#152563 (Replace "bug" with "issue" in triagebot ping messages)
- rust-lang/rust#152565 (fix missleading error for tuple ctor)
Failed merges:
- rust-lang/rust#152512 (core: Implement feature `float_exact_integer_constants`)
- rust-lang/rust#152296 (Port `rust_nonnull_optimization_guaranteed` and `rustc_do_not_const_check` to the new attribute parser)
doc: move riscv64a23-unknown-linux-gnu to tier 2
This updates the platform support documentation to reflect that "riscv64a23-unknown-linux-gnu" is now Tier 2.
-Docs-only change (no compiler/runtime behavior change).
Fixesrust-lang/rust#152539
bootstrap: add explicit UTF-8 encoding to text-mode open() calls
Make text-mode `open()` calls in `bootstrap.py`
explicitly use `encoding="utf-8"`.
This avoids relying on platform-dependent default encodings
when running Python < 3.15.
Binary-mode opens remain unchanged.
Update cargo submodule
8 commits in 0c9e687d237ff04b53ccb67b4ce63e9483789e88..ce69df6f72a3b6a2b5c722ba68ddef255344b31c
2026-02-11 05:58:30 +0000 to 2026-02-12 12:39:45 +0000
- fix: apply `host.runner` only when `host-config` enabled (rust-lang/cargo#16631)
- fix(cli): Improve bad manifest error (rust-lang/cargo#16630)
- fix: Adjust casing of error message (rust-lang/cargo#16625)
- Enable triagebot new `[view-all-comments-link]` feature (rust-lang/cargo#16629)
- test(help): snapshot cargo help tests (rust-lang/cargo#16626)
- Suggest a `workspace.members` entry even from outside the workspace root (rust-lang/cargo#16616)
- Reorganize build unit directory layout for new build-dir layout (rust-lang/cargo#16542)
- Make the error messaging for `cargo install` aware of `build.build-dir` (rust-lang/cargo#16623)
Start using pattern types in libcore (NonZero and friends)
part of rust-lang/rust#136006
This PR only changes the internal representation of `NonZero`, `NonMax`, ... and other integral range types in libcore. This subsequently affects other types made up of it, but nothing really changes except that the field of `NonZero` is now accessible safely in contrast to the `rustc_layout_scalar_range_start` attribute, which has all kinds of obscure rules on how to properly access its field.
Correctly check if a macro call is actually a macro call in rustdoc highlighter
Fixesrust-lang/rust#151904.
Issues was that if there was a `!` following an ident, we would always assume it's a macro call... except it's very lacking. I'm actually surprised it went for so long unnoticed. To fix it, I added a check for the next (non-blank) token after the `!`, if it's a `{` or a `[` or a `(`, then only do we consider it to be a macro call.
r? @lolbinarycat
Update books
## rust-lang/book
1 commits in 39aeceaa3aeab845bc4517e7a44e48727d3b9dbe..05d114287b7d6f6c9253d5242540f00fbd6172ab
2026-02-03 15:19:04 UTC to 2026-02-03 15:19:04 UTC
- Temporarily remove the link to `Drop::drop` (rust-lang/book#4576)
## rust-lang/nomicon
1 commits in 050c002a360fa45b701ea34feed7a860dc8a41bf..b8f254a991b8b7e8f704527f0d4f343a4697dfa9
2026-01-29 12:15:01 UTC to 2026-01-29 12:15:01 UTC
- Fix deprecation warning for compare_and_swap in atomics.md (rust-lang/nomicon#519)
## rust-lang/reference
12 commits in 990819b86c22bbf538c0526f0287670f3dc1a67a..addd0602c819b6526b9cc97653b0fadca395528c
2026-02-04 14:35:59 UTC to 2026-01-26 18:02:14 UTC
- const-eval.const-expr.field: make paragraph more clear (rust-lang/reference#2157)
- make more clear what the link target is (rust-lang/reference#2156)
- Update two URLs (rust-lang/reference#2154)
- Add a chapter on divergence (rust-lang/reference#2067)
- Guarantee `repr(C)` union field offset (rust-lang/reference#2128)
- Reference updates for forbidding object lifetime changing pointer casts (rust-lang/reference#1951)
- Clarify only arrays undergo unsized coercion during dispatch (rust-lang/reference#2139)
- Split the textual chapter into separate char and str chapters (rust-lang/reference#2145)
- Document ppc inline asm support (rust-lang/reference#2056)
- Unwrap items, expressions, patterns, and types (rust-lang/reference#2141)
- undefined behavior: add missing plural in `undefined.misaligned.ptr` (rust-lang/reference#2146)
- inline-assembly: add a space to the `asm.abi-clobbers.many` example (rust-lang/reference#2144)
Format heterogeneous try blocks
The tracking issue for `try_blocks_heterogeneous` is https://github.com/rust-lang/rust/issues/149488.
This follows the formatting of homogeneous try blocks (feature `try_blocks`) by considering `try bikeshed <type>` to be the equivalent of `try` (in particular a single "token").
An alternative would be to permit breaking between `bikeshed` and `<type>`, but given that those 2 elements are an explicitly temporary part of the syntax, it doesn't seem worth it. There also doesn't seem to be any existing precedent breaking between a keyword and a type. It also doesn't seem to be useful in practice, given that the type itself doesn't break (which is how it works for the return type of closures) and has more chances to dominate the length in case a break is necessary.
Happy to adapt anything in case this formatting is not optimal.
The test is also copied from homogeneous try blocks with 2 additional test cases to demonstrate the behavior with long types.
See [#t-lang > try blocks @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/try.20blocks/near/572387493) for context.
Remove `SubdiagMessage` in favour of the identical `DiagMessage`
For https://github.com/rust-lang/rust/issues/151366
Just some more cleanup :)
SubdiagMessage is now identical to DiagMessage, so there's no point in having both of them