Add Item::from_def_id_and_kind to reduce duplication in rustdoc

[jyn514]

This makes it harder to make typos, and also makes it much more clear what's intentionally different rather than a typo (look for what_rustc_thinks).

Found this while working on #76998, I really didn't want to add const_visibility in 20 different places.

r? @GuillaumeGomez

[jyn514]

@petrochenkov do you understand this error?

error: internal compiler error: compiler/rustc_middle/src/ty/query/mod.rs:105:1: `tcx.visibility(DefId(0:4 ~ foo[8787]::Bar))` unsupported by its crate
query stack during panic:
#0 [visibility] computing visibility of `Struct`
end of query stack

I can change it to use the hir::Visibility instead, but do you know why it's necessary?

[jyn514]

It's coming from this code:

impl Clean<Item> for doctree::Struct<'_> {
    fn clean(&self, cx: &DocContext<'_>) -> Item {
        Item::from_hir_id_and_kind(
            self.id,
            StructItem(Struct {
                struct_type: self.struct_type,
                generics: self.generics.clean(cx),
                fields: self.fields.clean(cx),
                fields_stripped: false,
            }),
            cx,
        )
    }
}

[jyn514]

Hmm, this comes from impl Default for Providers. Maybe rustdoc forgot to call providers::provide somewhere?

[jyn514]

Looks like the crate that should provide this is

rust/compiler/rustc_metadata/src/rmeta/decoder/cstore_impl.rs

Line 204 in d902752

visibility => { cdata.get_visibility(def_id.index) }

[petrochenkov]

@jyn514

error: internal compiler error: compiler/rustc_middle/src/ty/query/mod.rs:105:1: tcx.visibility(DefId(0:4 ~ foo[8787]::Bar)) unsupported by its crate

IIRC, the visibility query is only implemented for other crates, but not for the current crate (LOCAL_CRATE).
You could try implementing it for the local crate, it would be generally useful, I think.
Every time Visibility::from_hir is used, that new query could be used instead.
It's preferable to do that as a separate PR because there may be performance effects.

[petrochenkov]

#78077 has landed.

[jyn514]

Rebased and updated. This is still panicking on most tests:

error: internal compiler error: compiler/rustc_middle/src/hir/map/mod.rs:477:41: couldn't find hir id HirId { owner: DefId(0:0 ~ union[8787]), local_id: 0 } in the HIR map

Backtrace:

   8: rustc_middle::util::bug::bug_fmt
             at ./compiler/rustc_middle/src/util/bug.rs:14:5
   9: rustc_middle::hir::map::Map::get::{{closure}}
             at ./compiler/rustc_middle/src/hir/map/mod.rs:477:41
  10: core::option::Option<T>::unwrap_or_else
             at ./library/core/src/option.rs:427:21
  11: rustc_middle::hir::map::Map::get
             at ./compiler/rustc_middle/src/hir/map/mod.rs:477:9
  12: rustc_middle::ty::<impl rustc_middle::ty::context::TyCtxt>::opt_item_name::{{closure}}
             at ./compiler/rustc_middle/src/ty/mod.rs:2796:32
  13: core::option::Option<T>::and_then
             at ./library/core/src/option.rs:662:24
  14: rustc_middle::ty::<impl rustc_middle::ty::context::TyCtxt>::opt_item_name
             at ./compiler/rustc_middle/src/ty/mod.rs:2794:9
  15: rustdoc::clean::types::Item::from_def_id_and_kind
             at ./src/librustdoc/clean/types.rs:127:19
  16: rustdoc::clean::types::Item::from_hir_id_and_kind
             at ./src/librustdoc/clean/types.rs:118:9
  17: <rustdoc::doctree::Module as rustdoc::clean::Clean<rustdoc::clean::types::Item>>::clean
             at ./src/librustdoc/clean/mod.rs:265:33
  18: rustdoc::clean::utils::krate
             at ./src/librustdoc/clean/utils.rs:44:22

I think the issue is that opt_item_name doesn't check for the crate root, only item_name:

rust/compiler/rustc_middle/src/ty/mod.rs

Lines 2793 to 2797 in cee5521

	pub fn opt_item_name(self, def_id: DefId) -> Option<Ident> {
	def_id
	.as_local()
	.and_then(|def_id| self.hir().get(self.hir().local_def_id_to_hir_id(def_id)).ident())
	}

rust/compiler/rustc_middle/src/ty/mod.rs

Lines 2919 to 2934 in cee5521

	pub fn item_name(self, id: DefId) -> Symbol {
	if id.index == CRATE_DEF_INDEX {
	self.original_crate_name(id.krate)
	} else {
	let def_key = self.def_key(id);
	match def_key.disambiguated_data.data {
	// The name of a constructor is that of its parent.
	rustc_hir::definitions::DefPathData::Ctor => {
	self.item_name(DefId { krate: id.krate, index: def_key.parent.unwrap() })
	}
	_ => def_key.disambiguated_data.data.get_opt_name().unwrap_or_else(|| {
	bug!("item_name: no name for {:?}", self.def_path(id));
	}),
	}
	}
	}

I'll try rewriting item_name in terms of opt_item_name and see if that helps.

[jyn514]

@Manishearth FYI - Guillaume and I discussed offline that there's no way to get precisely the previous behavior back. I can recover pub(self) (in theory, I need to work out exactly how) and pub(super), but the previous behavior with super::b::super will always be normalized to pub(super) now - the information about how it was written just isn't present in the metadata, only in the HIR.

[Manishearth]

Yeah that's fine, I care about self and super only, the others are rare enough

[jyn514]

@bors r=petrochenkov rollup=never

I want to be able to bisect if this causes regressions.

[bors]

📌 Commit 46a99790cdf4dc633fe8b295b506b15c7ad72f1c has been approved by petrochenkov

[jyn514]

@bors r=petrochenkov rollup=never

[bors]

📌 Commit 0e1a302 has been approved by petrochenkov

[bors]

⌛ Testing commit 0e1a302 with merge c4f836a...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing c4f836a to master...

[jyn514]

@petrochenkov thank you so much for all your help, I wouldn't have been able to do this without you :)