Skip to content

rustdoc: never link to unnamable items #143849

New issue

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

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

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions src/librustdoc/html/format.rs
Original file line number Diff line number Diff line change
Expand Up @@ -367,6 +367,8 @@ pub(crate) enum HrefError {
Private,
// Not in external cache, href link should be in same page
NotInExternalCache,
/// Refers to an unnamable item, such as one defined within a function or const block.
UnnamableItem,
}

// Panics if `syms` is empty.
Expand Down Expand Up @@ -490,6 +492,20 @@ fn generate_item_def_id_path(
Ok((url_parts, shortty, fqp))
}

/// Checks if the given defid refers to an item that is unnamable, such as one defined in a const block.
fn is_unnamable(tcx: TyCtxt<'_>, did: DefId) -> bool {
let mut cur_did = did;
while let Some(parent) = tcx.opt_parent(cur_did) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this code is wrong: we can link to an impl associated item even if the impl is in a const/function block.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right, i think impls should break with a return false and only modules should continue up...

well technically we can only link to an impl item if the thing being impl'd on is nameable, but i'm not sure if that's something observable.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just discovered that we can have modules in any blocks. Dark magic. XD

Copy link
Member

@GuillaumeGomez GuillaumeGomez Jul 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, if the item is not public, it'll be stripped so should be fine. (for impl block as parents)

match tcx.def_kind(parent) {
// items defined in these can be linked to
DefKind::Mod | DefKind::Impl { .. } | DefKind::ForeignMod => cur_did = parent,
// everything else does not have docs generated for it
_ => return true,
}
}
return false;
}

fn to_module_fqp(shortty: ItemType, fqp: &[Symbol]) -> &[Symbol] {
if shortty == ItemType::Module { fqp } else { &fqp[..fqp.len() - 1] }
}
Expand Down Expand Up @@ -563,6 +579,9 @@ pub(crate) fn href_with_root_path(
}
_ => original_did,
};
if is_unnamable(cx.tcx(), did) {
return Err(HrefError::UnnamableItem);
}
let cache = cx.cache();
let relative_to = &cx.current;

Expand Down
12 changes: 12 additions & 0 deletions tests/rustdoc/reexport/auxiliary/wrap-unnamable-type.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
pub trait Assoc {
type Ty;
}

pub struct Foo(<Foo as crate::Assoc>::Ty);

const _X: () = {
impl crate::Assoc for Foo {
type Ty = Bar;
}
pub struct Bar;
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to have this as a dependency for this test? Can't it be done within the current crate?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, what happens if the const is named X?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The bug only happens during cross-crate re-exports. Otherwise a separate failsafe kicks in.

I was under the impression that the _ was a delibraerately injected placeholder, but maybe it is just the constant name, if so we'll need a more principled approach.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, yeah, you're right, my assumptions were wrong. Just looking at the path isn't enough.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to check what kind of item (block more precisely) the parent is. If it's not a module, then it's likely wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any idea what datastructure would retain that info in the cross-crate case? I'm somewhat struggling to understand how we even reconstruct path info and such from an rlib.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Path doesn't matter here, you need to check what is its parent.

16 changes: 16 additions & 0 deletions tests/rustdoc/reexport/wrapped-unnamble-type-143222.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
//@ compile-flags: -Z normalize-docs --document-private-items -Zunstable-options --show-type-layout
//@ aux-build:wrap-unnamable-type.rs
//@ build-aux-docs

// regression test for https://github.com/rust-lang/rust/issues/143222
// makes sure normalizing docs does not cause us to link to unnamable types
// in cross-crate reexports.

#![crate_name = "foo"]

extern crate wrap_unnamable_type as helper;

//@ has 'foo/struct.Foo.html'
//@ !hasraw - 'struct.Bar.html'
#[doc(inline)]
pub use helper::Foo;
Loading