rustdoc: elide cross-crate default generic arguments

[fmease]

Elide cross-crate generic arguments if they coincide with their default.
TL;DR: Most notably, no more Box<…, Global> in std's docs, just Box<…> from now on.
Fixes#80379.

Also helps with #44306. Follow-up to #103885, #107637.

r? @ghost

[Noratrieb]

@bors try @rust-timer queue

[bors]

⌛ Trying commit f31a6b80759ee614f3129d3dbe19ca3813a27baf with merge 00b673e3d61a9a1f3ac390d17266429e1f530a2a...

[bors]

☀️ Try build successful - checks-actions
Build commit: 00b673e3d61a9a1f3ac390d17266429e1f530a2a (00b673e3d61a9a1f3ac390d17266429e1f530a2a)

[fmease]

Actually now that I think about it, for this case, Ty == Ty is actually more than sufficient ^^. There's no need to ever normalize or unify if we only ever want to reelide generic args (i.e only elide args filled in by the compiler, not the user) and don't care about general elision. A pure syntactic check after subst'ing is enough for that. has_projections()? has_escaping_bound_vars()? Shouldn't matter. False negatives > bad perf. Maybe has_infer() matters but it's not reachable here.

All tests except three pass with just == and those tests are not something we want to support I guess. In CtPair<{1 + 2}, 3> (user-written), I don't see a practical reason in eliding 3 even though it would technically be correct. Same with Proj<(), bool> to Proj<()> or Alpha<for<'arbitrary> fn(&'arbitrary ())> to Alpha. Correct but expensive & useless.

@Nilstrieb this might be interesting to you (#107393). Definitely in favor of the lint but this here might just be another good counterexample :P. Unless I've missed something ^^' What do you think? :)

[rust-timer]

Finished benchmarking commit (00b673e3d61a9a1f3ac390d17266429e1f530a2a): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.4%	[0.2%, 0.6%]	10
Regressions ❌ (secondary)	0.6%	[0.2%, 0.9%]	12
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[0.2%, 0.6%]	10

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.7%	[2.7%, 2.7%]	1
Improvements ✅ (primary)	-4.4%	[-4.6%, -4.3%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-4.4%	[-4.6%, -4.3%]	3

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.0%	[1.7%, 2.3%]	2
Regressions ❌ (secondary)	2.1%	[1.6%, 2.5%]	7
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.6%	[-2.6%, -2.6%]	1
All ❌✅ (primary)	2.0%	[1.7%, 2.3%]	2

Binary size

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

Bootstrap: 647.29s -> 648.437s (0.18%)

[tgross35]

I saw your comment about perf and pointed out some places where closures could potentially be replaced. I know this is typically better for libs compile times but not sure whether it has any external effect here - figure it's something to try though.

[tgross35]

Can you refactor this closure to a nested function definition? If it doesn't actually close on its environment, it could be a bit better for perf

[tgross35]

Suggested change

	let aggressively_liberate = |arg: ty::Binder<'tcx,T>| {
	tcx.fold_regions(arg.skip_binder(), |r, _| match*r {
	ty::ReLateBound(_, br) => ty::Region::new_free(tcx, did, br.kind),
	_ => r,
	})
	};
	let actual = aggressively_liberate(actual);
	let default = aggressively_liberate(default);
	def aggressively_liberate(arg: ty::Binder<'tcx,T>, tcx: ...) -> ...{
	tcx.fold_regions(arg.skip_binder(), |r, _| match*r {
	ty::ReLateBound(_, br) => ty::Region::new_free(tcx, did, br.kind),
	_ => r,
	})
	};
	let actual = aggressively_liberate(actual, tcx);
	let default = aggressively_liberate(default, tcx);

Same as above (you could do similar with that inside closure)

[bors]

☔ The latest upstream changes (presumably #113591) made this pull request unmergeable. Please resolve the merge conflicts.

[Dylan-DPC]

@fmease any updates on this?

[fmease]

Ah, yes, I'm still working on it. Tried to improve perf but started working on other things. I'm gonna pick this up latest at end of the week.

[fmease]

@bors try @rust-timer queue

[bors]

⌛ Trying commit b44e1c3 with merge 578189dbe5426bae563bbf21074a1c84a4954a3f...

[fmease]

Perf is now neutral.

r? @GuillaumeGomez (feel free to reassign tho if you're short on time)

[GuillaumeGomez]

Great work, thanks!

@bors r+ rollup

[bors]

📌 Commit 58a80c8 has been approved by GuillaumeGomez

It is now in the queue for this repository.