Fixes wrong unreachable_pub lints on nested and glob public reexport

[lambinoo]

Linked issues: #64762 & #82064

[rust-highfive]

r? @nagisa

(rust-highfive has picked a reviewer for you, use r? to override)

[lambinoo]

r? @petrochenkov

[lambinoo]

I've had one test weirdly failing locally in the debuginfo-gdb pass but I'm not too sure how it can be related to my change

[petrochenkov]

What I wanted to achieve with #82064 is assigning all Public and Exported levels in resolve, to all items, not only exports.
The EmbargoVisitor::access_levels table will be pre-initialized from the resolver table.
(After that we'll be able to add an assert to EmbargoVisitor::update making sure that only Reachable and ReachableFromImplTrait levels are inserted at that point.)

[lambinoo]

@petrochenkov Hey, good evening! I've been able to look at the necessary work during the week. Would that basically involve moving a big chunk of the code from the EmbargoVisitor in rustc_privacy to a new PrivacyVisitor in rustc_resolve?

I already have some local changes towards that goal but I prefer to ask before sinking too much time in the wrong direction

[petrochenkov]

Most of EmbargoVisitor is about Reachable and ReachableFromImplTrait so there's not much to move if you want to support Public and Exported only.
Only modules (in resolve sense, including enums and traits) need to be treated specially, all other items don't need to be visited in detail at all.

[lambinoo]

@petrochenkov Mmmh, I've noticed what I think is a major blocker.

As far as I know, I cannot correctly resolve the access level of Impl contained inside a Block from the Resolver. I need access to a TyCtxt for that.

rust/compiler/rustc_privacy/src/lib.rs

Lines 639 to 641 in 8759f00

	hir::ItemKind::Impl { .. } => {
	Option::<AccessLevel>::of_impl(item.hir_id(), self.tcx, &self.access_levels)
	}

https://github.com/rust-lang/rust/blob/86bd8913c953a34c8bd4fd59dbdd46620c5419a5/compiler/rustc_privacy/src/lib.rs#L357-L364

Current workarounds I found are:

• being overly optimistic (and mark every pub items as Public) and rely on the types being private to throw errors
• keeping a Public/Exported access level pass in rustc_privacy explicitely for Impl which is what I did
  https://github.com/rust-lang/rust/blob/86bd8913c953a34c8bd4fd59dbdd46620c5419a5/compiler/rustc_privacy/src/lib.rs#L589-L598

My last push contains those changes (I still need to see how to handle macros so it's not finished yet)

[petrochenkov]

Ah, right, impls can also be public or exported.
You are right, you cannot correctly process impls early in resolve, the logic for impls will need to stay in rustc_privacy.

[petrochenkov]

@lambinoo
Has something changed?
I see that the clippy errors on CI are gone, but I don't see any changes in clippy.

[lambinoo]

I noticed a small mistake in the rustc_pricacy code. A line disappeared when I shuffled some code around.

I forgot to update the access level of the impl in visit_item (L650).

I found this in the most overkill way by having the compiler dump the access level structure and doing a diff between this branch and master... And a lot of impl that should have been public were missing.

[petrochenkov]

Great, hopefully it will pass now.
@bors r+

[bors]

📌 Commit 3a77bb8 has been approved by petrochenkov

[bors]

⌛ Testing commit 3a77bb8 with merge df035a3...

[bors]

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

[rust-timer]

Finished benchmarking commit (df035a3): comparison url.

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

• Moderate improvement in instruction counts (up to -1.1% on incr-unchanged builds of unused-warnings)

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

@rustbot label: -perf-regression

[lambinoo]

Success! Gosh this one has been cooking for a while. I'll be working on improving the whole resolution thing now but I think the two linked issues can be closed now!
I wanted to thank you @petrochenkov (again x3) for the time you gave me for this PR and for your patience!