rustdoc: re-elide cross-crate default trait-object lifetime bounds

[fmease]

Hide trait-object lifetime bounds (re-exported from an external crate) if they coincide with their default.
Partially addresses #44306. Follow-up to #103885. Zulip discussion.

Most notably, if std exported something from core containing a type like Box<dyn Fn()>, then it would now be rendered as Box<dyn Fn(), Global> instead of Box<dyn Fn() + 'static, Global> (hiding + 'static as it is the default in this case). Showing Global here is a separate issue, #80379, which is on my agenda.

Note that I am not really fond of the fact that I had to add a parameter to such a widely used function (30+ call sites) to address such a niche bug.

CC @GuillaumeGomez
Requesting a review from a compiler contributor or team member as recommended on Zulip.
r? compiler

---

@rustbot label T-compiler T-rustdoc A-cross-crate-reexports

[GuillaumeGomez]

The changes look good to me, thanks for working on this! I think it'd be nice to have someone from the compiler team to also take a look at this to confirm that it's the right solution and also another person from rustdoc to ensure I didn't miss something.

cc @davidtwco @notriddle

[GuillaumeGomez]

@bors try @rust-timer queue

[bors]

⌛ Trying commit c62daa166c21ffb8c12d6df6f1cab6edcb310ed3 with merge c0b38d8c099b44a2e66768efae13b34971552f9d...

[bors]

💔 Test failed - checks-actions

[fmease]

Spurious network failure as far as I can tell 😞, could you please retry?

[GuillaumeGomez]

@bors try @rust-timer queue

[bors]

⌛ Trying commit c62daa166c21ffb8c12d6df6f1cab6edcb310ed3 with merge d784b9581340dda4299f1b68760e703b72c91231...

[bors]

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

[rust-timer]

Finished benchmarking commit (d784b9581340dda4299f1b68760e703b72c91231): comparison URL.

Overall result: ❌✅ regressions and improvements - 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
Regressions ❌ (secondary)	0.5%	[0.3%, 0.7%]	7
Improvements ✅ (primary)	-1.0%	[-1.5%, -0.5%]	3
Improvements ✅ (secondary)	-3.6%	[-4.2%, -3.2%]	6
All ❌✅ (primary)	-1.0%	[-1.5%, -0.5%]	3

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)	7.4%	[7.4%, 7.4%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.1%	[-2.1%, -2.1%]	1
All ❌✅ (primary)	-	-	0

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)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.6%	[-5.3%, -1.9%]	7
Improvements ✅ (secondary)	-2.2%	[-2.2%, -2.2%]	1
All ❌✅ (primary)	-3.6%	[-5.3%, -1.9%]	7

[davidtwco]

r? compiler

[notriddle]

This all looks okay to me as well.

[GuillaumeGomez]

Then let's go! Thanks to everyone involved!

@bors r=notriddle,cgillot,GuillaumeGomez

[bors]

📌 Commit 5b5d84f has been approved by notriddle,cgillot,GuillaumeGomez

It is now in the queue for this repository.

[bors]

⌛ Testing commit 5b5d84f with merge 7820972...

[bors]

☀️ Test successful - checks-actions
Approved by: notriddle,cgillot,GuillaumeGomez
Pushing 7820972 to master...

[rust-timer]

Finished benchmarking commit (7820972): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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.3%, 0.9%]	12
Regressions ❌ (secondary)	0.7%	[0.3%, 0.9%]	18
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[0.3%, 0.9%]	12

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)	3.3%	[3.3%, 3.3%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.3%	[3.3%, 3.3%]	1

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: 650.406s -> 649.872s (-0.08%)

[fmease]

perf-regression

Right, that was to be expected (doing more work for every single trait object type) and we've already seen this in the 2nd of 3 perf runs. Let me know if this is acceptable or if I should try to make this faster (fast path or cache maybe?). I'm already delaying as much work as possible (hence ContainerTy instead of eagerly computing things).

[notriddle]

I think it’s fine, anyway.

[fmease]

Ok, then
@rustbot label perf-regression-triaged

[QuineDot]

Heads up: This PR seems to be based around the reference's section on default trait object lifetimes, but that section of the reference is inaccurate in many ways. I imagine the main cases for Rustdoc would be

• Trait bounds usually override type bounds, not the other way around

  use std::any::Any;
  fn common_example(r: &dyn Any) -> &(dyn Any + 'static) {
      // This line fails so the reference lifetime is not the default lifetime
      // (And if it was, the reference lifetime would have to be `'static`)
      let _: &'static dyn Any = r;
      r
  }

  trait Bound<'a, 'b>: 'a {}
  fn another_example<'a: 'b, 'b>(r: &dyn Bound<'a, 'b>) {
      // This compiles so the reference lifetime is not the default lifetime
      let _: &(dyn Bound<'a, 'b> + 'a) = r;
  }

• Type aliases bounds (or lack of bounds) take precedence over bounds on what they alias

  use std::fmt::Display;
  type Alias<'a, T> = &'a T;
  type Surprise<'a> = Alias<'a, dyn Display>;
  
  // This compiles
  fn example(s: Surprise<'_>) -> &(dyn Display + 'static) { s }

Unfortunately the exception to trait bounds overriding types bound is "in function signatures, sometimes" (when no bound parameters are late bound or 'static). The exact rules for what the actual default lifetime is in function signatures is sadly a giant mess.

I'm not sure what the best way to actually test Rustdoc on this matter is, but would be willing to give it a shot if there's some guidance on how to test Rustdoc somewhere.

[fmease]

I've been meaning to reply to this comment of yours for a while now but I've since forgotten about it. I'm not an expert on region checking and I haven't carefully read the implementation of object lifetime defaults yet but I'm gonna check each snippet you posted over at rust-lang/reference. Some things definitely look fishy

[fmease]

Also note that most of the things you listed here and over at rust-lang/reference shouldn't be relevant to rustdoc since they only affect types found in bodies (function, closure, constant) which rustdoc doesn't (really) render.