rustdoc: deterministic sorting for `doc_cfg` badges
Fixesrust-lang/rust#156391
Currently, target-exclusive `doc_cfg` badges (eg. "Available on...") reuse the order of predicates as they appear in the source code. This often buries popular targets behind niche ones and leads to inconsistent UI rendering.
This PR introduces a deterministic sorting mechanism to the `Cfg` AST prior to HTML/JSON rendering.
**Note for Reviewers:**
To provide the best UX, I implemented a lightweight tiering heuristic (prioritizing major platforms like Linux/Apple/Windows first, followed by mobile, then BSDs, and alphabetizing the rest). However, I am completely open to tweaking these priority groupings or falling back to a different sorting logic if the team prefers. Let me know what you think!
Fix jump to def link generation on primitive type associated methods
Fixesrust-lang/rust#156707.
Interestingly enough, the inference fails on primitive type, so instead I go around a bit by generating a `PrimitiveType` and then tweak a bit the `href` generation.
r? @fmease
rustdoc: properly support macros with multiple kinds
Since it seems like I can't reopen https://github.com/rust-lang/rust/pull/145458, opening this one. Although, it's the same PR minus the last new commit to handle a comment that was left unresolved in the original PR. All relevant details are still in the original PR though.
It's an alternative (and likely a take-over) of https://github.com/rust-lang/rust/pull/148005 since lang-team rejected the idea to add documentation on macro branches, making the multiple files approach less suitable.
This implements rust-lang/rust#145153 in rustdoc. This PR voluntarily doesn't touch anything related to intra-doc links, I'll send a follow-up if needed.
So now about the implementation itself: this is a weird case where a macro can be different things at once but still only gets one file generated. I saw two ways to implement this:
1. Handle `ItemKind::Macro` differently and iter through its `MacroKinds` values.
2. Add new placeholder variants in the `ItemKind` enum, which means that when we encounter them in rendering, we need to ignore them. It also makes the `ItemKind` enum bigger (and also needs more code to be handled). Another downside is that it needs to be handled in the JSON output.
Now there was an interesting improvement that came with this PR in the `html::render::print_item::item_module` function: I simplified its implementation and split the different parts in a `HashMap` where the key is the item type. So then, we can just iterate through the keys and open/close the section at each iteration instead of keeping an `Option<section>` around.
From RFCs:
* https://github.com/rust-lang/rust/pull/144579
* https://github.com/rust-lang/rust/pull/145208
derive:
<img width="442" height="327" alt="Screenshot From 2026-04-18 03-11-40" src="https://github.com/user-attachments/assets/f69587a0-8a2b-4080-bc8a-b63dd18f21c1" />
attr:
<img width="442" height="327" alt="Screenshot From 2026-04-18 03-11-31" src="https://github.com/user-attachments/assets/bf9b235a-9d2f-435c-a91e-167562df6b68" />
both:
<img width="442" height="327" alt="Screenshot From 2026-04-18 03-11-50" src="https://github.com/user-attachments/assets/b7e8b3c6-eb99-495b-bdf9-17ba8fb4da0d" />
r? @notriddle
Correctly handle associated items in rustdoc macro expansion
Fixesrust-lang/rust#156075.
The bug was simply that it didn't cover associated items.
r? @Urgau
rustdoc: preserve parent doc cfg for `macro_export` macros
The detached-item context is discovered before `propagate_doc_cfg`, it is carried on the clean item and consumed by the pass.
Closesrust-lang/rust#100916
Move `std::io::ErrorKind` to `core::io`
* Update `rustdoc-html` tests for the new path
* Add `core_io` feature to control stability. This replaces the use of `core_io_borrowed_buf` on the `core::io` module itself.
* Re-export `core::io::ErrorKind` in `std::io::error`
rustdoc: preserve `doc(cfg)` on locally re-exported type aliases
When a type alias is locally re-exported from a private module (an implicit inline), rustdoc drops its `cfg` attributes because it treats it like a standard un-inlined re-export. Since type aliases have no inner fields to carry the `cfg` badge (unlike structs or enums), the portability info is lost entirely.
This patch explicitly preserves the target's `cfg` metadata when the generated item is a `TypeAliasItem`, ensuring the portability badge renders correctly without breaking standard cross-crate re-export behavior.
Fixesrust-lang/rust#154921
When a type alias is locally re-exported from a private module (an implicit
inline), rustdoc drops its `cfg` attributes because it treats it like a
standard un-inlined re-export. Since type aliases have no inner fields to
carry the `cfg` badge (unlike structs or enums), the portability info
is lost entirely.
This patch explicitly preserves the target's `cfg` metadata when the
generated item is a `TypeAliasItem`, ensuring the portability badge
renders correctly without breaking standard cross-crate re-export behavior.
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" />
When explicitly re-exporting a declarative macro by name, rustdoc
previously bypassed intermediate re-exports and dropped `#[doc(inline)]`
attributes, causing the macro to be incorrectly stripped if the original
definition was `#[doc(hidden)]`.
This updates `generate_item_with_correct_attrs` to walk the
`reexport_chain` specifically for declarative macros, allowing them to
inherit inline attributes exactly as glob imports do, while preserving
strict visibility rules for standard items.
rustdoc ICE fix: When collecting `Deref` impls with their targets, skip the negative ones
rustdoc assumed every `Deref` impl has an associated `Target` type, but negative impls (e.g. `impl !Deref for T {}`) have none.
Skip them in both the trait-impl collection pass and the HTML render pass to avoid panicking on the missing `Target`.
Closesrust-lang/rust#128801.
Allow merging all libcore/alloc doctests into a single binary
This is only the changes needed to *allow* merging the tests. This doesn't actually turn doctest merging on in bootstrap. I think that might be a useful follow-up, since it makes them much faster to run, but it's not without downsides because it means we'll no longer be testing that doctests have all necessary `feature()` attributes.
The motivation for this change is to run the tests with `-C instrument-coverage` and then generate a coverage report from the output. Currently, this is very expensive because it requires parsing DWARF for each doctest binary. Merging the binaries decreases the time taken from several hours to ~30 seconds.
---
There are several parts to this change, most of which are independent and I'm happy to split out into other PRs.
- Upgrade process spawning logging from debug->info so it's easier to see, including in a rustdoc built without debug symbols.
- Core doctests now support being run with `-C panic=abort`. Ferrocene needs this downstream for complicated reasons; it's a one-line change so I figured it's not a big deal.
- Downgrade errors about duplicate features from a hard error to a warning. The meaning is clear here, and doctest merging often creates duplicate features since it lifts them all to the crate root. This involves changes to the compiler but generally I expect this to be low-impact.
- Enable this new warning, as well as several related feature lints, in rustdoc. By default rustdoc doesn't lint on anything except the lints it manually adds.
- Rustdoc now treats `allow(incomplete_features)` as a crate-level attribute, just like `internal_features`. Without this, it's possible to get hard errors if rustdoc lifts features to the crate level but not `allow`s.
- Core doctests now support being built with `--merge-doctests=yes`. In particular, I removed a few `$crate` usages and explicitly marked a few doctests as `standalone_crate`.
rustdoc: don't give depreciation notes special handling
based on discussion in rust-lang/rust#149741
we're currently using pre-wrap here which forces us to do a bunch of other hacky weird stuff, but getting rid of all that would likely break some existing docs, so i'm proposing we do it across an edition.
r? @GuillaumeGomez
Add regression test for `doc(fake_variadic)` on reexports
Follow-up of https://github.com/rust-lang/rust/pull/153136. Out of the four doc attributes remaining to be tested (`fake_variadic`, `keyword`, `attribute` and `notable_trait`), only `fake_variadic` could have been impacted by reexports:
* `attribute` and `keyword` are not supposed to be reexported (they're supposed to be used on private modules)
* `notable_trait` is applied to a trait, so whether it's reexported or not, it still works.
r? @lolbinarycat
Fix relative path handling for --extern-html-root-url
When `--extern-html-root-url` receives a relative path (like `../`), rustdoc uses it as a literal prefix regardless of page depth. This works at depth 1 (`crate/index.html`) but breaks at depth 2+ (`crate/module/struct.Foo.html`) because the relative path doesn't account for the extra nesting.
This patch detects relative vs absolute URLs in the `Remote` branch of `url_parts` and prepends the necessary `../` segments based on the current page depth. Absolute URLs (`https://...`) and server-absolute paths (`/docs/...`) are unchanged.
This makes relative paths a viable option for `--extern-html-root-url`, which they weren't before.
Related to rust-lang/rust#152917, which exposed that relative paths weren't handled correctly.
cc @eggyal
Implement RFC 3678: Final trait methods
Tracking: https://github.com/rust-lang/rust/issues/131179
This PR is based on rust-lang/rust#130802, with some minor changes and conflict resolution.
Futhermore, this PR excludes final methods from the vtable of a dyn Trait.
And some excerpt from the original PR description:
> Implements the surface part of https://github.com/rust-lang/rfcs/pull/3678.
>
> I'm using the word "method" in the title, but in the diagnostics and the feature gate I used "associated function", since that's more accurate.
cc @joshtriplett
Jonathan Brouwer