Skip to content

rustdoc shows associated type in supertrait bound twice when both Deref and DerefMut have a Target bound #122928

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
RalfJung opened this issue Mar 23, 2024 · 3 comments
Assignees
Labels
A-associated-items Area: Associated items (types, constants & functions) A-cross-crate-reexports Area: Documentation that has been re-exported from a different crate C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@RalfJung
Copy link
Member

This is visible here:

pub trait AllocBytes: Clone + Debug + Eq + PartialEq + Hash + Deref<Target = [u8], Target = [u8]> + DerefMut {

Compared to the actual sources, the Target = [u8] is duplicated at Deref but missing at DerefMut.

pub trait AllocBytes:
    Clone + fmt::Debug + Eq + PartialEq + Hash + Deref<Target = [u8]> + DerefMut<Target = [u8]>

(On DerefMut the constraint is redundant, that is likely what is throwing rustdoc off.)

Cc @rust-lang/rustdoc

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Mar 23, 2024
@fmease fmease self-assigned this Mar 23, 2024
@fmease fmease added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. C-bug Category: This is a bug. A-associated-items Area: Associated items (types, constants & functions) A-cross-crate-reexports Area: Documentation that has been re-exported from a different crate and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Mar 23, 2024
@fmease
Copy link
Member

fmease commented Mar 23, 2024

I've been aware of flaws like this for a long time (your issue is an instance of the more general #113015) and I generally know how to fix this but work has stalled (e.g. this tangentially related PR #116735) because the way data is represented in rustdoc (rustdoc::clean::types) makes this unnecessarily hard to implement (if not impossible) with respect to correctness and performance. If I were to work with rustc data types directly (cc #76382), it would be a piece of cake.

@fmease
Copy link
Member

fmease commented Mar 23, 2024

I really want to fix issues like this though, let me take another look.

@RalfJung
Copy link
Member Author

Thanks!

Closing in favor of #113015 then.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-associated-items Area: Associated items (types, constants & functions) A-cross-crate-reexports Area: Documentation that has been re-exported from a different crate C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants