Skip to content

Shorten types more when only interesting part is lifetimes#158992

Open
estebank wants to merge 2 commits into
rust-lang:mainfrom
estebank:shorten-type-highlighted-lt
Open

Shorten types more when only interesting part is lifetimes#158992
estebank wants to merge 2 commits into
rust-lang:mainfrom
estebank:shorten-type-highlighted-lt

Conversation

@estebank

@estebank estebank commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

We have a mechanims (Highlight) to change the name of inferred lifetimes in types so that we can refer to them by a number. Modify it so that it also avoids printing sub-parts of the type that are irrelevant to the situation at hand. The new behavior will print any sub part that has any lifetime (as they might be informative) instead of just the lifetimes being replaced. This was found to produce the best effect empirically in the test suite, striking a nice balance between shortening labels and being informative.

error: lifetime may not live long enough
  --> $DIR/wrong-closure-arg-suggestion-125325.rs:46:18
   |
LL |         take(|_| to_fn(|_| self.counter += 1));
   |              --- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ returning this value requires that `'1` must outlive `'2`
   |              | |
   |              | return type of closure `aux::Map<{closure@...}>` contains a lifetime `'2`
   |              lifetime `'1` represents this closure's body
   |
   = note: closure implements `Fn`, so references to captured variables can't escape the closure
error: implementation of `FnOnce` is not general enough
  --> $DIR/higher-ranked-auto-trait-15.rs:20:5
   |
LL |     require_send(future);
   |     ^^^^^^^^^^^^^^^^^^^^ implementation of `FnOnce` is not general enough
   |
   = note: closure with signature `fn(&'0 ...) -> std::slice::Iter<'_, i32>` must implement `FnOnce<(&'1 Vec<i32>,)>`, for any two lifetimes `'0` and `'1`...
   = note: ...but it actually implements `FnOnce<(&Vec<i32>,)>`

Made this change after noticing that the first of the errors above had a corresponding .stderr file with lines longer than 150 columns by using rg ".. \| .{150}" -g *.stderr.

estebank added 2 commits July 9, 2026 03:19
We have a mechanims (`Highlight`) to change the name of inferred lifetimes in types so that we can refer to them by a number. Modify it so that it also avoids printing sub-parts of the type that are irrelevant to the situation at hand. The new behavior will print any sub part that has *any* lifetime (as they might be informative) instead of *just* the lifetimes being replaced. This was found to produce the best effect empirically in the test suite, striking a nice balance between shortening labels and being informative.

```
error: lifetime may not live long enough
  --> $DIR/wrong-closure-arg-suggestion-125325.rs:46:18
   |
LL |         take(|_| to_fn(|_| self.counter += 1));
   |              --- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ returning this value requires that `'1` must outlive `'2`
   |              | |
   |              | return type of closure `aux::Map<{closure@...}>` contains a lifetime `'2`
   |              lifetime `'1` represents this closure's body
   |
   = note: closure implements `Fn`, so references to captured variables can't escape the closure
```
```
error: implementation of `FnOnce` is not general enough
  --> $DIR/higher-ranked-auto-trait-15.rs:20:5
   |
LL |     require_send(future);
   |     ^^^^^^^^^^^^^^^^^^^^ implementation of `FnOnce` is not general enough
   |
   = note: closure with signature `fn(&'0 ...) -> std::slice::Iter<'_, i32>` must implement `FnOnce<(&'1 Vec<i32>,)>`, for any two lifetimes `'0` and `'1`...
   = note: ...but it actually implements `FnOnce<(&Vec<i32>,)>`
```

Made this change after noticing that the first of the errors above had a corresponding `.stderr` file with lines longer than 150 columns.
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 9, 2026
@rustbot

rustbot commented Jul 9, 2026

Copy link
Copy Markdown
Collaborator

r? @mejrs

rustbot has assigned @mejrs.
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

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler
  • compiler expanded to 75 candidates
  • Random selection from 18 candidates

Comment on lines +10 to +11
= note: expected signature `fn(ValueRef<'1>) -> Result<(&'2 str, &'1 &'2 str), ...>`
found signature `fn(ValueRef<'1>) -> Result<(&'1 str, &'1 &'1 str), ...>`

@estebank estebank Jul 9, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not using the "highlighted expected/found" we use for E0308... It'll likely require extending that logic to also learn to replace lifetime names in the same way that Highlight does.

View changes since the review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants