closure capture migrations do not note when move is now required

[m-ou-se]

In a small crater run for the 2021 edition migrations, a few problems shows up with closures no longer compiling after migration:

• https://crater-reports.s3.amazonaws.com/pr-87190-2/try%23d8627d19850b63702b76089d7b055730e9ddca14/reg/finality-grandpa-0.14.3/log.txt
• https://crater-reports.s3.amazonaws.com/pr-87190-2/try%23d8627d19850b63702b76089d7b055730e9ddca14/reg/tantivy-0.15.3/log.txt
• https://crater-reports.s3.amazonaws.com/pr-87190-2/try%23d8627d19850b63702b76089d7b055730e9ddca14/reg/tetsy-finality-grandpa-0.13.0/log.txt

[m-ou-se]

cc @rust-lang/wg-rfc-2229 (This is the issue for the problem I mentioned here.)

[roxelo]

@arora-aman I think you may have more context on this one

[nikomatsakis]

We discussed this on Zulip. The root cause here is that sometimes move mode is not required for a thread-spawn because the closure the only upvar that a closure referenced, it used to move -- but now, in Rust 2021, because we have a more precise path, we are able to get away with a copy, which winds up being "by ref" (playground).

This is a migration failure but we decided to not fix it, it's a bit annoying, but instead just leave a comment in the Rust 2021 Edition guide explaining that this scenario comes up in some isolated cases and suggesting how to fix it.

Therefore: the fix will be opening a PR against rust-lang/edition-guide (which can close this issue).

[arora-aman]

@nikomatsakis another case: #88444

[Enselic]

Triage: This is explained in https://doc.rust-lang.org/edition-guide/rust-2021/disjoint-capture-in-closures.html I think?

Even if this issue is not fixed, I would argue it is not worth spending time to fix, because if no one has complained for 5 years, no one is likely ever going to complain.

But, again, I think this has already been fixed.