`super let` improves diagnostics

[CAD97]

When $name:ident is provided to an expression guard! macro using super let, we can improve diagnostics to more clearly indicate which two guards are improperly entangled:

error[E0716]: temporary value dropped while borrowed
  --> src/lib.rs:242:36
   |
 9 |     let (a, b) = (guard!(guard_a), guard!(guard_b));
   |                                    ^^^^^^^^^^^^^^^ creates a temporary value which is freed while still in use
...
12 | }
   | -
   | |
   | temporary value is freed at the end of this statement
   | borrow might be used here, when `guard_a` is dropped and runs the `Drop` code for type `LifetimeBrand`
   |
   = note: consider using a `let` binding to create a longer lived value
   = note: this error originates in the macro `guard` (in Nightly builds, run with -Z macro-backtrace for more info)

Note that make_guard!(guard_b) is pointed to and guard_a is named. We can get similar from make_guard!:

error[E0716]: temporary value dropped while borrowed
  --> src/lib.rs:262:5
   |
10 |     make_guard!(b);
   |     ^^^^^^^^^^^^^^ creates a temporary value which is freed while still in use
...
13 | }
   | -
   | |
   | temporary value is freed at the end of this statement
   | borrow might be used here, when `a` is dropped and runs the `Drop` code for type `LifetimeBrand`
   |
   = note: consider using a `let` binding to create a longer lived value
   = note: this error originates in the macro `make_guard` (in Nightly builds, run with -Z macro-backtrace for more info)

even without super let, and I will make that improvement, but using the same name for the Guard (which the caller can name) and the LifetimeBrand (which they can't) makes the error less clear than naming them separately.

make_guard! cannot easily provide different names for the brand and the guard¹, as the caller being able to name the brand place would violate soundness. super let (currently) does not make the place name in scope of the super scope, despite the lifetime continuing.

blocked on: rust-lang/rust#139076

Footnotes

1. It could make the binding and then shadow it with another binding, but I consider that to cause a problematic user experience since the binding is usable with an unexpected type. ↩