Change:
&raw const $place } <ins> pub macro addr_of_crate($place:expr) { &raw const $place } pub macro addr_of_super($place:expr) { &raw const $place } </ins> pub macro addr_of_self($place:expr) { &raw const $place } <del> pub macro addr_of_crate($place:expr) { </del> <ins> pub macro addr_of_local($place:expr) { </ins> &raw const $place } pub struct Foo; <del> pub struct FooSelf; </del> pub struct FooCrate; <ins> pub struct FooSuper; pub struct FooSelf; pub struct FooLocal; </ins> pub enum Bar { Foo, } <del> pub enum BarSelf { Foo, } </del> pub enum BarCrate { Foo, } <ins> pub enum BarSuper { Foo, } pub enum BarSelf { Foo, } pub enum BarLocal { Foo, } </ins> pub fn foo() {} <del> pub fn foo_self() {} </del> pub fn foo_crate() {} <ins> pub fn foo_super() {} pub fn foo_self() {} pub fn foo_local() {} </ins> pub type Type = i32; <del> pub type TypeSelf = i32; </del> pub type TypeCrate = i32; <ins> pub type TypeSuper = i32; pub type TypeSelf = i32; pub type TypeLocal = i32; </ins> pub union Union { a: i8, b: i8, } <ins> pub union UnionCrate { a: i8, b: i8, } pub union UnionSuper { a: i8, b: i8, } </ins> pub union UnionSelf { a: i8, b: i8, } <del> pub union UnionCrate { </del> <ins> pub union UnionLocal { </ins> a: i8, b: i8, }

Discussion:
I tried this code: I expected to see this happen: The documentation is empty. Instead, this happened: ! <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: rustdoc 1.58.0-nightly ( 2021-11-12) cc I suspect this is related to one of your recent changes to visibility.
This does appear to have been . I'm not entirely sure how to fix this. Basically, what's happening here is that the query is checking if the use statement is accessible from its parent module. It is, because the parent module of the top level of the module is itself. Before this, it would have been documented if you did a , but not with just . The new behavior is more consistent, and better in that sense, but perhaps not ideal. Do you have an idea on how you'd like this to work?
Some additional thoughts: If we want to stick to the "visible from parent module" thing, the simplest way to do that would be to add a check for whether is the top level module. Of course, I'd also have to add a check for the visibility being actually public... sighs. Might need to break this into a seperate thing. I guess the problem I'm struggling with after thinking about all of this is that I don't fully understand the justification for all of this logic. Why is it that we want to show some imports but not others? If these were structs, we'd just show all of them, regardless of their visibility. That said, if this really is the behavior we want, it shouldn't be hard to implement.
I think we should inline neither nor bare (pretty sure I said so on the PR, but I guess I forgot to check for a test case). Because the structs are only visible from the module where they're defined. The use statements aren't intended to be used from elsewhere in the crate.
I think I explained this poorly above. We generally don't inline either or bare . Not doing so is the intended behavior from the PR. Because of how I implemented it, the top of the crate ended up being an inadvertent exception, and we didn't have any tests that covered the top of the crate as opposed to lower level modules.

It's an easy fix if we want it not to be an exception, I was just trying to make sure we had a clear philosophical reason for wanting things to be the way we were trying to have them be. (In other words, I was double-checking that the behavior the PR was supposed to create is really what we want before submitting a PR to do that.) It sounds like it is, so I'll get working on a bugfix. I feel like I'm expressing myself rather unclearly at the moment. If there's anything I need to clear up about this explanation, please feel free to let me know.
Oh oops, I missed this bit. Yes, I think this should be consistent with the submodules of the crate.
I agree, that sounds like the right behavior to me.
Quick update: I've got a substantive patch, but it's taking a while to get the tests to a point where I'm satisfied with them.
My PR is up! Also, I'm going to assign this as a , per the discussion in of the prioritization working group.