Repository navigation
Rustdoc "Auto Trait Implementations" is showing private types instead of the relevant generic bounds #162274
Description
Code
pub struct Foo<T>(Bar<T>);
struct Bar<T>(Box<T>);Or, see a standard library type such as Vec.
Reproduction Steps
cargo doc --open- Visit the "Auto Traits" section of
Foo
OR
Expected Outcome
Auto trait implementations should, as they do on stable, show their bounds in terms of the generics of the type.
impl<T> Send for Foo<T>
where
T: Send,impl<T, A> Send for Vec<T, A>
where
A: Send,
T: Send,Actual Output
impl<T> Send for Foo<T>
where
Bar<T>: Send,Bar is a private type and should not appear in the documentation.
impl<T, A> Send for Vec<T, A>
where
RawVec<T, A>: Send,RawVec is a private type and should not appear in the documentation.
This prevents users from understanding what the actual bounds on the impl are, because Bar and RawVec may have bounds that are not the obvious ones.
Version
rustdoc 1.100.0-nightly (2e2b193 2026-09-02)
Does not reproduce on 1.98.0 or 1.99.0-beta.3 (cbae9b4 2026-08-28)
Additional Details
@rustbot label regression-from-stable-to-nightly
Metadata
Metadata
Assignees
Labels
Area: auto traits (e.g., `auto trait Send {}`)Area: Synthetic impls, used by rustdoc to document auto traits and traits with blanket implsCategory: This is a bug.Relevant to the rustdoc team, which will review and decide on the PR/issue.The Rustc Trait System Refactor Initiative (-Znext-solver)Performance or correctness regression from stable to nightly.This issue requires a nightly compiler in some way. When possible, use a F-* label instead.
Activity
fmease commentedon Sep 4, 2026
This is due to two facts:
-Znext-solver=globally#158346)In the meantime, pass
-Znext-solver=coherenceto revert to the previous behavior.fmease commentedon Sep 4, 2026
Why can't we just continue to use the current implementation of the auto trait synthesizer when the next solver is enabled? Well, it uses the
selectAPI which is no longer supported by the next solver IIRC, it abuses some APIs that are meant to be private IINM & it's generally incredibly janky and painful to look at.The actual solution for all of this is my PR #149019 from last year which stalled because I find this feature incredibly nasty to implement and I wasn't funded anymore at the time. Given your report and the fact that I'm funded again, I think I'm morally obliged to pick up this work again (which is fine).
Of course, there's a semi-tight deadline of probably only a few months until the next trait solver gets stabilized (I don't make any guarantees here, this is hearsay).
fmease commentedon Sep 4, 2026
However, the current version of PR #149019 is not the final approach & can't be merged as is. lcnr & I discussed a slightly tweaked approach last year that requires some rewriting and retesting.
ds84182 commentedon Oct 15, 2026
Christmas is here early: #164209