privacy: cache for trait ref in projection

[bvanjoi]

Fixes #145741

Performance test results from local for #145741:

time cargo clean && cargo build: 20.60s
time cargo +stage1 clean && cargo +stage1 build: 11.29s

I'm uncertain if this is a completely correct fix, as I've just reviewed the privacy update logic and it appears that a single update should suffice in the alias term. Feel free to close this if there are any algorithmic inaccuracies, and I'll investigate further.

[rustbot]

r? @SparrowLii

rustbot has assigned @SparrowLii.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[lqd]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 97bca8b (97bca8b377025fbbb752947ef69ee3c8bc9ec6f5, parent: a2c8b0b92c14b02f0b3f96a0d5296f1090dc286b)

[rust-timer]

Finished benchmarking commit (97bca8b): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.1%, 0.2%]	12
Regressions ❌ (secondary)	0.1%	[0.1%, 0.2%]	5
Improvements ✅ (primary)	-0.3%	[-0.4%, -0.1%]	7
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.0%	[-0.4%, 0.2%]	19

Max RSS (memory usage)

Results (primary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.3%	[1.3%, 1.3%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.6%	[-1.6%, -1.6%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.1%	[-1.6%, 1.3%]	2

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 465.026s -> 467.402s (0.51%)
Artifact size: 388.33 MiB -> 388.34 MiB (0.00%)

[SparrowLii]

r? @petrochenkov Could you have a look of this, Vadim?

[petrochenkov]

This is only correct to do if in all concrete DefIdVisitors visit_trait always does the same thing for the same trait_ref and that thing is not affected by mutable state in the visitor.

[petrochenkov]

TypePrivacyVisitor and SearchInterfaceForPrivateItemsVisitor clearly satisfy that condition by not having any mutable state, but I'm not so sure about ReachEverythingInTheInterfaceVisitor and ReachableContext.

[petrochenkov]

ReachEverythingInTheInterfaceVisitor and ReachableContext seem to also be idempotent.

[petrochenkov]

I want to check some different caching strategies for this in #147486.
@rustbot blocked

From local testing, caching at DefId level doesn't help with #145741, you have to skip larger pieces of code to improve compilation times for it.