Closure formatting in diagnostics can be a bit verbose

[jieyouxu]

Consider inputs like

rust/tests/ui/closures/closure-clone-requires-captured-clone.rs

Line 1 in 278a909

//! Test that closures only implement `Clone` if all captured values implement `Clone`.

, the diagnostics is:

rust/tests/ui/closures/closure-clone-requires-captured-clone.stderr

Lines 1 to 8 in 278a909

	error[E0277]: the trait bound `NonClone: Clone` is not satisfied in `{closure@$DIR/closure-clone-requires-captured-clone.rs:13:19: 13:26}`
	--> $DIR/closure-clone-requires-captured-clone.rs:17:13
	|
	LL | let closure = move || {
	| ------- within this `{closure@$DIR/closure-clone-requires-captured-clone.rs:13:19: 13:26}`
	...
	LL | closure.clone();
	| ^^^^^ within `{closure@$DIR/closure-clone-requires-captured-clone.rs:13:19: 13:26}`, the trait `Clone` is not implemented for `NonClone`

The message mentioning the closure uses a format like

 LL |     let closure = move || { 
    |                   ------- within this `{closure@$DIR/closure-clone-requires-captured-clone.rs:13:19: 13:26}` 

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

[jieyouxu]

(I'm almost certain there's an earlier issue or two about this, but I couldn't find it based on a cursory search.)

[estebank]

CC #99927, #19939

[xonx4l]

@jieyouxu I think we can set a global path for multiple closures in order to reduce repetitiveness?

[jieyouxu]

@jieyouxu I think we can set a global path for multiple closures in order to reduce repetitiveness?

That won't work if you have multiple crates as the context, I think? Haven't thought too hard about it.

[estebank]

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

[xonx4l]

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.

[jieyouxu]

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