Repository navigation
Closure formatting in diagnostics can be a bit verbose #148236
Description
Activity
- changed the title
[-]Closures[/-][+]Closure formatting in diagnostics can be a bit verbose[/+]on Oct 29, 2025 (I'm almost certain there's an earlier issue or two about this, but I couldn't find it based on a cursory search.)
Reacted by Esteban KuberI just realized that there's a closure format that I haven't seen discussed before: when the closure is from the current file, use
{closure@13:19: 13:26}. We already shorten their names in some cases to not include the full path and only print the file name and byte range. At that point, if we really want to shorten them, we can do{closure@13:19}, but I fear removing the file name will be confusing for people (and I don't think we have the machinery to realize what file we're printing a type for).I just realized that there's a closure format that I haven't seen discussed before: when the closure is from the current file, use
{closure@13:19: 13:26}. We already shorten their names in some cases to not include the full path and only print the file name and byte range. At that point, if we really want to shorten them, we can do{closure@13:19}, but I fear removing the file name will be confusing for people (and I don't think we have the machinery to realize what file we're printing a type for).To build on your idea, if we are going to shorten it, I think {closure@13:19} is better than {closure@13:19: 13:26} but If the closure is in a different file this becomes ambiguous.
I just realized that there's a closure format that I haven't seen discussed before: when the closure is from the current file, use
{closure@13:19: 13:26}. We already shorten their names in some cases to not include the full path and only print the file name and byte range. At that point, if we really want to shorten them, we can do{closure@13:19}, but I fear removing the file name will be confusing for people (and I don't think we have the machinery to realize what file we're printing a type for).Yeah, the trade-off is between having more info but appearing a bit verbose, or showing less info but risk losing useful context. Particularly because closures are anonymous, and so can only be identified uniquely through their file path + span info.
Between appearing a bit verbose and losing context, I think retaining sufficient context is more important, because otherwise the user would have to reverse engineer which closure we are talking about.
(This is issue was mostly that I was wondering if we could somehow shorten the representation without (substantial) loss of info, but I guess I don't see how yet.)
Consider inputs like
rust/tests/ui/closures/closure-clone-requires-captured-clone.rs
Line 1 in 278a909
rust/tests/ui/closures/closure-clone-requires-captured-clone.stderr
Lines 1 to 8 in 278a909
The message mentioning the closure uses a format like
which feels quite verbose. I guess the span [lo, hi) (in terms of (start, end) line/col) and file path do make it clear which closure is being referred to when there are multiple closures. So not a priority, just tracking this in case there's ways to perhaps make this a bit more concise without losing info -- or assess if that info is actually fully needed).