ICE with intra-doc link [value@Enum::Variant]

[coolreader18]

I'm probably planning on working on this, I found it while I was working on #130587. The issue is that rustdoc looks up Foo::X in the value namespace, which returns a Ctor, not a Variant. Turns out giving doc comments unimpeded access to the rustc resolver might not be a perfect idea 🙃

This seems slightly (but not very) tricky to fix, mainly an ironing out of semantics - do we pretend that Foo::X in the value namespace doesn't exist? Or do we let you reference it, but taking care not to say that there's a conflict between Foo::X (the constructor) and Foo::X (the variant) and that you have to disambiguate it?

Code

/// [value@Foo::X]
pub enum Foo {
    X,
}

Meta

rustdoc --version --verbose (current master):

rustdoc 1.83.0-dev
binary: rustdoc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.83.0-dev
LLVM version: 19.1.0

Error output

thread 'rustc' panicked at src/librustdoc/clean/utils.rs:529:14:
register_res: unexpected Def(Ctor(Variant, Const), DefId(0:7 ~ field_ice[155b]::Boo::X::{constructor#0}))

Backtrace

stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: rustdoc::clean::utils::register_res
   3: <rustdoc::passes::collect_intra_doc_links::LinkCollector as rustdoc::visit::DocVisitor>::visit_item
   4: <rustdoc::passes::collect_intra_doc_links::LinkCollector as rustdoc::visit::DocVisitor>::visit_item_recur
   5: <rustdoc::passes::collect_intra_doc_links::LinkCollector as rustdoc::visit::DocVisitor>::visit_item
   6: <rustdoc::passes::collect_intra_doc_links::LinkCollector as rustdoc::visit::DocVisitor>::visit_crate
   7: rustdoc::passes::collect_intra_doc_links::collect_intra_doc_links
   8: <rustc_session::session::Session>::time::<rustdoc::clean::types::Crate, rustdoc::core::run_global_ctxt::{closure#6}>
   9: rustdoc::core::run_global_ctxt
  10: <rustc_session::session::Session>::time::<core::result::Result<(rustdoc::clean::types::Crate, rustdoc::config::RenderOptions, rustdoc::formats::cache::Cache), rustc_span::ErrorGuaranteed>, rustdoc::main_args::{closure#2}::{closure#0}::{closure#0}::{closure#0}>
  11: <std::thread::local::LocalKey<core::cell::Cell<*const ()>>>::with::<rustc_middle::ty::context::tls::enter_context<<rustc_middle::ty::context::GlobalCtxt>::enter<rustdoc::main_args::{closure#2}::{closure#0}::{closure#0}, core::result::Result<(), rustc_span::ErrorGuaranteed>>::{closure#1}, core::result::Result<(), rustc_span::ErrorGuaranteed>>::{closure#0}, core::result::Result<(), rustc_span::ErrorGuaranteed>>
  12: <rustc_middle::ty::context::GlobalCtxt>::enter::<rustdoc::main_args::{closure#2}::{closure#0}::{closure#0}, core::result::Result<(), rustc_span::ErrorGuaranteed>>
  13: <rustc_interface::queries::QueryResult<&rustc_middle::ty::context::GlobalCtxt>>::enter::<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustdoc::main_args::{closure#2}::{closure#0}::{closure#0}>
  14: <rustc_interface::interface::Compiler>::enter::<rustdoc::main_args::{closure#2}::{closure#0}, core::result::Result<(), rustc_span::ErrorGuaranteed>>
  15: <scoped_tls::ScopedKey<rustc_span::SessionGlobals>>::set::<rustc_interface::util::run_in_thread_with_globals<rustc_interface::util::run_in_thread_pool_with_globals<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustdoc::main_args::{closure#2}>::{closure#1}, core::result::Result<(), rustc_span::ErrorGuaranteed>>::{closure#0}, core::result::Result<(), rustc_span::ErrorGuaranteed>>::{closure#0}::{closure#0}::{closure#0}, core::result::Result<(), rustc_span::ErrorGuaranteed>>
  16: rustc_span::create_session_globals_then::<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_interface::util::run_in_thread_with_globals<rustc_interface::util::run_in_thread_pool_with_globals<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustdoc::main_args::{closure#2}>::{closure#1}, core::result::Result<(), rustc_span::ErrorGuaranteed>>::{closure#0}, core::result::Result<(), rustc_span::ErrorGuaranteed>>::{closure#0}::{closure#0}::{closure#0}>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[jyn514]

Or do we let you reference it, but taking care not to say that there's a conflict between Foo::X (the constructor) and Foo::X (the variant) and that you have to disambiguate it?

i'm not sure why we would want this - you can't document the constructor separately from the variant, so i would expect rustdoc to hide it from intra-doc links

[jyn514]

(or alternatively we could make value@Enum::Variant an alias for type@Enum::Variant)

[notriddle]

First of all, I can reproduce this problem with a unit-like struct.

/// [value@MyStruct]
pub struct MyStruct;

Second of all,

do we pretend that Foo::X in the value namespace doesn't exist

This is an observable fact. To see it, use glob exports.

pub enum MyEnum {
   Internals,
}

pub use MyEnum::*;

/// In this context, [type@Internals] is a struct, while [value@Internals] is an enum variant.
pub struct Internals {
    foo: (),
}

Most crates probably won't do this... but most crates probably won't need disambiguators at all. These things are in the value namespace, and that's a fact that can be observed in the surface language, so we probably shouldn't pretend otherwise.