Fix ICE when nameless borrowed binding is dropped

[slashnick]

With -Znll-dump-cause, when a borrow check fails because of a DropVar, the LocalDecl for that variable may not have a name.

Fixes #47646

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @michaelwoerister (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[kennytm]

Thanks for the PR! We’ll periodically check in on it to make sure that @michaelwoerister or someone else from the team reviews it soon.

[pietroalbini]

@michaelwoerister ping from triage! This PR needs a review.

[shepmaster]

r? @Zoxc

[Zoxc]

r? @nikomatsakis

[nikomatsakis]

So, the PR seems fine, but I wonder if we can do better with the error message. I had to resort to reading the MIR to better understand what is happening here.

For those curious: the variableborrow is being moved into the tuple, and the tuple is then dropped (not borrow).

[nikomatsakis]

I think what I would want is maybe something like:

error[E0502]: cannot borrow `heap` as immutable because it is also borrowed as mutable
  --> $DIR/issue-47646.rs:25:30
   |
21 |     let borrow = heap.peek_mut();
   |                  ---- mutable borrow occurs here
...
24 |         match (borrow, ()) {
   |               ------------ borrow may end up in a temporary, created here
25 |             println!("{:?}", heap); //~ ERROR cannot borrow `heap` as immutable
   |                              ^^^^ immutable borrow occurs here
...
28 |     };
   |      - temporary later dropped here, potentially using the reference

error: aborting due to previous error

[nikomatsakis]

We could produce that, I suppose, by

• finding the temporary being dropped
• searching for the span of where it is assigned
  • hopefully it is assigned only once =)
• and using that span for the "borrow may end up in a temporary, created here"

If there are multiple assignments, maybe we give up, and just say "borrow may be used when a temporary value is dropped here" or something.

[nikomatsakis]

@nickfrostatx what do you think? =) You be up for that?

[slashnick]

@nikomatsakis Sure, that would be a much more helpful message. I'll try to get that working.

[pietroalbini]

Hi @nickfrostatx, did you get that working so this PR can be merged?

[pietroalbini]

@nickfrostatx thank you for taking the time to send this PR! Unfortunately, there was no activity in it for more than two weeks, so I'm closing this. If you have time to work on it again in the future feel free to open another one, we'll be happy to review and merge it!