`Not Found` error for the hyperlink from `rustc_middle::ty::TypeFlags` to `InternalBitFlags`

[cushionbadak]

Location

When press InternalBitFlags type hyperlink in https://doc.rust-lang.org/stable/nightly-rustc/rustc_middle/ty/struct.TypeFlags.html

Summary

The hyperlink links to https://doc.rust-lang.org/stable/nightly-rustc/rustc_type_ir/flags/_/struct.InternalBitFlags.html , which is broken.

The document is rendered like this:

pub struct TypeFlags([InternalBitFlags](https://doc.rust-lang.org/stable/nightly-rustc/rustc_type_ir/flags/_/struct.InternalBitFlags.html));

I guess InternalBitFlags has no dedicated type definition, as TypeFlags itself is a struct, not containing other type.

rust/compiler/rustc_type_ir/src/flags.rs

Lines 11 to 19 in 35f6036

	pub struct TypeFlags: u32 {
	// Does this have parameters? Used to determine whether instantiation is
	// required.
	/// Does this have `Param`?
	const HAS_TY_PARAM = 1 << 0;
	/// Does this have `ReEarlyParam`?
	const HAS_RE_PARAM = 1 << 1;
	/// Does this have `ConstKind::Param`?
	const HAS_CT_PARAM = 1 << 2;

[lolbinarycat]

The bitflags! macro rewrites the struct definition, and defines InternalBitFlags within a const block, creating an unnameable type. It then uses a doc(hidden) trait in order to expose that type and use it outside of the const block.

[lolbinarycat]

Weirdly, when I try to reproduce this in a standalone crate, rustdoc seems quite robust, never linking to items that don't exist, and always referring to the internal type as it is written, through the associated type. I wonder if this has something to do with an unstable option or attribute that we use for internal docs. the rustc-dep-of-std feature of bitflags didn't seem to change anything.

[lolbinarycat]

Ah, -Znormalize-docs seems to be the first part of this puzzle, though even with that, rustdoc is still smart enough not to actually link to the nonexistent docs, instead generating a type name that is not a link.

[lolbinarycat]

Weirdly ./x doc compiler/rustc_middle/ doesn't reproduce this issue, but ./x doc compiler/ does.

[lolbinarycat]

Ah, of course, the last piece is to make it a cross-crate reexport.

[lolbinarycat]

Minimal reproducer:

// in crate `helper`
pub trait Assoc {
    type Ty;
}

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

const _: () = {
    impl crate::Assoc for Foo {
        type Ty = Bar;
    }
    pub struct Bar;
};

#[doc(inline)]
pub use helper::Foo;

Then run RUSTDOCFLAGS='-Z normalize-docs' cargo +nightly doc --document-private-items on the crate that reexports, and you'll get something like this:

where Bar leads to a missing page.

Weirdly --document-private-items is required for the link to be generated, but the field being private is not required.

This suggests the issue is that unnameable types are not getting stripped from foreign crates when --document-private-items is passed.