Avoid documenting top-level private imports

[inquisitivecrystal]

PR #88447 aimed to make rustdoc's --document-private-items mode only document imports that are visible outside the importing module. Unfortunately, I inadvertently set things up so that imports at the crate top-level are always documented, regardless of their visibility. This behavior was unintended and is not desirable.

This PR treats top-level imports as never being visible outside their parent module. In practice, the only way a top-level import can be visible externally is if it's fully public, and there's a seperate check for that.

It's worth calling attention to the fact that this change means that pub(crate) imports will be visible in lower level modules, but not at the top-level. This is because, at the top level of the crate, pub(crate) means the same thing as pub(self).

It turned out that there were existing tests checking for the only behavior, which I didn't notice at the time of my previous PR. I have updated them to check for the new behavior and substantially extended them to handle differences between the top-level module and lower level modules. I may have gone overboard, so please tell me if there's anything I should cut.

r? @jyn514

Fixes #90865.

[inquisitivecrystal]

I just realized it would probably be more readable if the order of the definitions in src/test/rustdoc/auxiliary/reexports.rs was the same as the order of the imports in src/test/rustdoc/reexports.rs and src/test/rustdoc/reexports-priv.rs. I'll fix that and force-push later.

[jyn514]

This is ... Quite a lot of tests 😂 the change to rustdoc itself looks fine, I'm going to wait to review the tests until you reorder them like you mentioned.

[inquisitivecrystal]

This is ... Quite a lot of tests 😂 the change to rustdoc itself looks fine, I'm going to wait to review the tests until you reorder them like you mentioned.

Done!

The way the existing tests were set up does imports with a bunch of different sorts of things. I suppose the idea is to make sure that different imported types don't break things? I've mirrored that in my new tests. It's possible that it would be helpful to test for different things, like different types of visibility, but that's not how the existing tests are set up.

[jyn514]

I think these tests are pretty overkill 😆 but overkill never hurt anything. Thanks for the quick fix!

@bors r+ p=1 (needs to land before the beta promotion on Friday)

[bors]

📌 Commit 3c51038 has been approved by jyn514

[bors]

⌛ Testing commit 3c51038 with merge 2e055d9...

[bors]

☀️ Test successful - checks-actions
Approved by: jyn514
Pushing 2e055d9 to master...

[rust-timer]

Finished benchmarking commit (2e055d9): comparison url.

Summary: This change led to very large relevant improvements 🎉 in compiler performance.

• Very large improvement in instruction counts (up to -45.1% on full builds of webrender-wrench)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

[inquisitivecrystal]

CC @nnethercote: these new results seem related to the perf regressions that were being attributed to #88447.

[nnethercote]

Excellent! Instruction counts went from ~5.9 billion to ~10.9 billion in #90769. This commit changes them from ~11.1 billion to ~6.1 billion. So it seems like there was a bit of movement elsewhere, but this PR gets back all of the big regression :)