[nll] better error message when returning refs to upvars

[pnkfelix]

In an example like:

rust/src/test/ui/issue-40510-1.rs

Lines 14 to 20 in 59fa6bd

	fn f() {
	let mut x: Box<()> = Box::new(());
	|| {
	&mut x
	};
	}

AST-borrowck accepts such code, but NLL will start rejecting it.

@nikomatsakis concluded in a comment back in April (#49824 (comment)) that similar code (or at least it looks similar to me) is in fact incorrect, and decided that NLL was correct in rejecting such cases.

This issue is just marking that this change in semantics has occurred, so that I can link to it from places like #52663

Known instances:

• NLL: unexpected "free region `` does not outlive" error #49824 (comment)
• https://github.com/rust-lang/rust/blob/59fa6bd6c14eebd213884da08a33639b4c848bb3/src/test/ui/issue-40510-1.rs
• https://github.com/rust-lang/rust/blob/59fa6bd6c14eebd213884da08a33639b4c848bb3/src/test/ui/issue-40510-3.rs

[pnkfelix]

tagging this with T-lang because it is one of the first cases on #52663 that I think they may want to dive into with @nikomatsakis

[cramertj]

It seems correct to reject this code as an FnMut, but it seems like it would be fine as an FnOnce that hands out a reference with a fixed lifetime.

I hit a similar issue with the current implementation of async closures in that they don't ever allow mutation of upvars because the returned closure-as-a-future can't be tied to the lifetime of the call to the closure. It would seem like mutation would be fine so long as the outer closure is FnOnce, but the compiler doesn't accept it.

[pnkfelix]

Its also important to note that @nikomatsakis 's comment (#49824 (comment)) was for a slightly different scenario, namely this (#49824 (comment))

fn main() {
    let mut x = 0;
    || {
        || {
            let _y = &mut x;
        }
    };
}

I'd need to review the list of instances here more carefully to determine whether every case that we hit has the same sort of issue (where if the user adds move to force it to be FnOnce, then things work).

At the very least we could try to tell them to do that as a hint.

[matthewjasper]

Note that AST borrowck rejects this if you try to call the closure.

[pnkfelix]

I'm not going to tag this with a particular NLL- triage label at the moment; I suspect @nikomatsakis will want to do so at the next WG-compiler-nll meeting.

I suspect the tag should be one of:

• NLL-diagnostics, in that we could improve the feedback to the user to advise them to add a move to their lambda expression, or
• NLL-complete, as in code we used to accept and should continue to accept via some means (be it "smarter" inference of FnOnce, or ... something else ... )