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