Shorten types more when only interesting part is lifetimes by estebank · Pull Request #158992 · rust-lang/rust

estebank · 2026-07-09T03:44:45Z

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 _) -> 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.

rustbot · 2026-07-09T03:44:50Z

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

estebank · 2026-07-09T15:53:32Z

+   = note: expected signature `fn(ValueRef<'1>) -> Result<(&'2 str, &'1 &'2 str), ...>`
+              found signature `fn(ValueRef<'1>) -> Result<(&'1 str, &'1 &'1 str), ...>`


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

mejrs

Thanks, this looks mostly okay to me. I have some thoughts.

@rustbot author

View changes since this review

mejrs · 2026-07-11T14:36:22Z

                    write!(self, "{coroutine_kind}")?;
-                    if coroutine_kind.is_fn_like() {
+                    if self.should_truncate() {
+                        write!(self, "@...}}")?;


I'm not a fan of printing @.... Here and elsewhere we end up printing something like {async closure@...}, {coroutine@...} and I think if shown out of context that'll be confusing.

Instead consider trimming the paths leading up to the file, so e.g. {async closure@dir/path/to/the/file.rs:LL:CC: LL:CC} becomes {async closure@file.rs:LL:CC: LL:CC}.

Or maybe we should just say {async closure}? 🤔

In any case most users will have module names much shorter than our test file's names, so I think the ui test output isn't really representative of what users get in the wild.

I could swear that we have some logic doing that, writing only the filename if the path is too long and we're shortening things... I need to check more closely where we do that.

I'm trying out this (making the output {async closure}) and the one below (using _ instead of ...) and will push on its own commit to show what it looks like.

mejrs · 2026-07-11T14:38:00Z

   |     ^^^^^^^^^^^^^^^^^^^^ implementation of `FnOnce` is not general enough
   |
-   = note: closure with signature `fn(&'0 Vec<i32>) -> std::slice::Iter<'_, i32>` must implement `FnOnce<(&'1 Vec<i32>,)>`, for any two lifetimes `'0` and `'1`...
+   = note: closure with signature `fn(&'0 ...) -> Iter<'_, i32>` must implement `FnOnce<(&'1 Vec<i32>,)>`, for any two lifetimes `'0` and `'1`...


This doesn't look like an improvement to me.

The removed Vec<i32> or the std::slice?

The fn(&'0 ...) part. ... in function signatures is a type (sort of) so this is an unacceptable regression in my eyes.

Does the change to &'0 _ change the equation for you?

It's still a bit weird, but I like it better.

estebank · 2026-07-12T19:50:10Z

@rustbot ready

mejrs

Overall it does look better to me. I'll have to think it over a bit. What do you think?

View changes since this review

mejrs · 2026-07-12T22:30:43Z

@@ -1,15 +1,15 @@
-error[E0369]: cannot add `(..., ..., ..., ...)` to `(..., ..., ..., ...)`
+error[E0369]: cannot add `((_, _, _, _), _, _, _)` to `((_, _, _, _), _, _, _)`


This is interesting, I think I like this better as well.

workingjubilee

Most of these do seem like improvements but I dunno about the closure type changes. Is it possible for these errors to ever be split across files, or located in such a large file, in such a way that the initial error line doesn't usefully indicate what I'm looking at? e.g. files with 5000 lines with 10 similar large closures that fill the screen.

But if we do want them, then I'm not sure we shouldn't just cut even more?

View changes since this review

workingjubilee · 2026-07-13T00:03:46Z

@@ -15,7 +15,7 @@ error: lifetime may not live long enough
 LL |         let x = async move || { &s };
   |                 ------------- ^^^^^^ returning this value requires that `'1` must outlive `'2`
   |                 |           |
-   |                 |           return type of async closure `{async closure body@$DIR/not-lending.rs:16:31: 16:37}` contains a lifetime `'2`
+   |                 |           return type of async closure `{async closure body}` contains a lifetime `'2`


Is this {async closure body} doing anything here? The previous variant indicated the type's location in a useful way, but here "async closure" is a complete idea, and we're possibly just wasting our breath on saying "the async closure that, btw, is an async closure..." Really, rustc? You don't say?

An alternative way to reduce the number of characters here would just be

return type of `{async closure@$DIR/not-lending.rs:16:31:16:37}` contains a lifetime `'2`

This removes about 16 characters that at least seem to me like no one could benefit from... about a 5th of the amount of content that can easily be scanned on a line if one adheres to the "3 alphabets" rule... without reducing the actual information transmitted. If the body is important, then we can keep that and still save a fair amount "for free".

For why not remove the in-file location: I'm worried that we're potentially losing the span info here, and relying on the end of the closure being easily findable from the start.

Also, pragmatically, even in a more conservative version, we could save more space by not including column numbers and mmmaybe intelligently collapsing them if they're on a single line? If someone puts multiple closures on a single line I do feel comfortable saying "...don't do that, though? or at least not if you want good diagnostics..." Sometimes generated code looks like that but formatters exist. That could look like...

return type of `{async closure body@$DIR/not-lending.rs:16}` contains a lifetime `'2`

We can make a distinction between a top-level closure-like type that got shortened and one that is in a type parameter. It is still useful to see Result<{closure}, Error>, specially when it is highly nested. In these errors, the most important bit of information is the lifetimes involved, not the types themselves (because those already type checked so they are right).

We might be able to check "is the span label this name going to be used in pointing at the closure itself?" to completely avoid the type...

I want to point out that in type errors where the distinction of closures is more important, on the expected/found note we do print the closure's span's fs path, so the information might not be included in a span label.

I'm not happy with the rendering of closure-likes in general, but we can argue about that elsewhere :)

Calling these "async closure body return type" is weird indeed. I'm intrigued why we did that in the first place.

Ok, looking at this more closely I realize what's going on:

The message is talking about "the return type for the closure being pointed at, which is {...}, contains lifetime 'x". That returned type is the evaluated type for the closure's body. So if we have |()| (), it would be (), but if we have |()| || (), it would be {closure@...}. This is confusing and removing the path is certainly a problem. But this gets even worse with async closures, because those get desugared to something like |_| async {} , so the return type of the outer closure is the async body. That's why we see these bizarre output. We need to fix an outright bug on these diagnostics when it comes to async closures.

Partly addressed the above in the last commit: we now present the right type, but the primary span used in these errors is incorrect, it should be pointing at the tail expression of the async closure, instead of the whole body of the closure.

workingjubilee · 2026-07-14T21:20:58Z

@@ -15,7 +15,7 @@ error: lifetime may not live long enough
 LL |         let x = async move || { &s };
   |                 ------------- ^^^^^^ returning this value requires that `'1` must outlive `'2`
   |                 |           |
-   |                 |           return type of async closure `{async closure body@$DIR/not-lending.rs:16:31: 16:37}` contains a lifetime `'2`
+   |                 |           return type of async closure is &'2 String


...Wow, yeah, my eyes had just kind of glazed over and I didn't really think about how this was... kinda babble? I'm glad I raised the point of "this should either keep more or cut more". This is enormously clearer.

View changes since the review

We still need to fix the Span to point at &s instead of { &s }, but I waded through that for a bit and I think I won't be fixing it myself anytime soon. 😬

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.

``` error[E0700]: hidden type for `impl Iterator<Item = u32>` captures lifetime that does not appear in bounds --> $DIR/static-return-lifetime-infered.rs:11:9 | LL | fn iter_values<'a>(&'a self) -> impl Iterator<Item=u32> { | -- ----------------------- opaque type defined here | | | hidden type `Map<std::slice::Iter<'a, ...>, {closure@...}>` captures the lifetime `'a` as defined here LL | self.x.iter().map(|a| a.0) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ ```

…ing types

…tening

rustbot · 2026-07-15T16:36:48Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

…n the *root* type This means that when we encounter a closure, we never hide it's path from the rendering, but if the closure is in a type parameter, it will get shortened. This should be fine for most lifetime errors to be understandable.

estebank · 2026-07-15T16:48:17Z

-   |                    hidden type `Map<std::slice::Iter<'a, (u32, u32)>, {closure@$DIR/static-return-lifetime-infered.rs:11:27: 11:30}>` captures the lifetime `'a` as defined here
+   |                    hidden type `Map<Iter<'a, _>, {closure@...}>` captures the lifetime `'a` as defined here
 LL |         self.x.iter().map(|a| a.0)
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^


One thing to improve would be making this primary span mention "this type captures lifetime 'a".

View changes since the review

mejrs

I like this, happy to approve it. Sorry/not sorry for sending you on this goose chase doing related changes 😆

Thanks to you and @workingjubilee for your work here. I'll give @workingjubilee some time to look over these changes.

View changes since this review

rustbot assigned mejrs Jul 9, 2026

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

estebank commented Jul 9, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

estebank force-pushed the shorten-type-highlighted-lt branch from ff889d6 to cd0972b Compare July 10, 2026 03:57

estebank mentioned this pull request Jul 10, 2026

E0308 with complex types produces an unhelpful expected type vs found type note #159043

Open

This comment has been minimized.

Sign in to view

mejrs reviewed Jul 11, 2026

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 11, 2026

This comment was marked as outdated.

Sign in to view

This comment was marked as off-topic.

Sign in to view

rustbot added the WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) label Jul 12, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 12, 2026

estebank force-pushed the shorten-type-highlighted-lt branch 3 times, most recently from 95cd4a6 to fe43871 Compare July 12, 2026 19:58

This comment has been minimized.

Sign in to view

mejrs reviewed Jul 12, 2026

View reviewed changes

workingjubilee reviewed Jul 13, 2026

View reviewed changes

estebank force-pushed the shorten-type-highlighted-lt branch from 0e61216 to b399d1a Compare July 13, 2026 17:07

This comment has been minimized.

Sign in to view

workingjubilee reviewed Jul 14, 2026

View reviewed changes

workingjubilee mentioned this pull request Jul 14, 2026

Account for async closures when pointing at lifetime in return type #159256

Merged

This comment has been minimized.

Sign in to view

estebank added 10 commits July 15, 2026 16:03

Teach async closures and coroutines to print short types

a85f928

Make Highlighted take heed of --verbose

76519dc

Account for for<'a> in <impl for<'a> Trait as Trait> when shorten…

24c30fb

…ing types

Always show full signature on "impl doesn't match trait" error

e94c07c

Tweak logic to refer to items by their name instead of path when shor…

d228a89

…tening

Fix typo

b8c0562

address review comments

23204b1

tidy

ec430cb

Do not change closure short type rendering

fa69dbd

estebank force-pushed the shorten-type-highlighted-lt branch from 8310ea8 to 2836709 Compare July 15, 2026 16:36

estebank added 3 commits July 15, 2026 16:37

Add missing backticks

247cf33

Tweak shortened closure logic

c6f5692

estebank force-pushed the shorten-type-highlighted-lt branch from 2836709 to c6f5692 Compare July 15, 2026 16:37

estebank commented Jul 15, 2026

View reviewed changes

mejrs approved these changes Jul 15, 2026

View reviewed changes

		= note: expected signature `fn(ValueRef<'1>) -> Result<(&'2 str, &'1 &'2 str), ...>`
		found signature `fn(ValueRef<'1>) -> Result<(&'1 str, &'1 &'1 str), ...>`

		@@ -1,15 +1,15 @@
		error[E0369]: cannot add `(..., ..., ..., ...)` to `(..., ..., ..., ...)`
		error[E0369]: cannot add `((_, _, _, _), _, _, _)` to `((_, _, _, _), _, _, _)`

Uh oh!

Uh oh!

Conversation

estebank commented Jul 9, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jul 9, 2026

Uh oh!

estebank Jul 9, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

mejrs left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mejrs Jul 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

This comment was marked as outdated.

This comment was marked as off-topic.

estebank commented Jul 12, 2026

Uh oh!

This comment has been minimized.

mejrs left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

workingjubilee left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

workingjubilee Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

workingjubilee Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

workingjubilee Jul 14, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

rustbot commented Jul 15, 2026

Uh oh!

estebank Jul 15, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

estebank commented Jul 9, 2026 •

edited by rustbot

Loading

estebank Jul 9, 2026 •

edited by rustbot

Loading

mejrs left a comment •

edited by rustbot

Loading

mejrs Jul 12, 2026 •

edited

Loading

mejrs left a comment •

edited by rustbot

Loading

workingjubilee left a comment •

edited by rustbot

Loading

workingjubilee Jul 13, 2026 •

edited

Loading

workingjubilee Jul 13, 2026 •

edited

Loading

workingjubilee Jul 14, 2026 •

edited by rustbot

Loading

estebank Jul 15, 2026 •

edited by rustbot

Loading

mejrs left a comment •

edited by rustbot

Loading