Tracking Issue for move expressions (`move(expr)`)

This is a tracking issue for move(expr) in closures.
The feature gate for the issue is #![feature(move_expr)].

RFC: https://github.com/rust-lang/rfcs/pull/3968
Relevant prior discussion / implementation PR: #132290.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g. bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Summary

move_expr adds syntax of the form move(expr) for explicit by-value capture in closures.

The current implementation effort is intentionally starting with plain closures first.
Async / coroutine-related cases are expected to follow separately.

Steps

• Create an RFC for move_expr
• Implement move(expr) for plain closures https://github.com/rust-lang/rust/pull/155023
• Implement async / coroutine-related cases https://github.com/rust-lang/rust/pull/157738
• Add and expand UI / borrowck / nested-closure test coverage
• Adjust documentation (see instructions on rustc-dev-guide)
• Style updates for any new syntax (nightly-style-procedure)
  • Style team decision on new formatting
  • Formatting for new syntax has been added to the Style Guide
  • (non-blocking) Formatting has been implemented in rustfmt
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• Async and coroutine cases: What should the semantics be for async blocks and coroutine-related lowering?
• Nested closures: Are the current expected bahavior of nested-closure the right ones in practice, or do they need adjustment?
• Diagnostics and linting: For accepted but potentially confusing cases, such as shadowing or label-related behavior, should we keep the behavior as-is, improve diagnostics, or add a dedicated lint?
• Control-flow-sensitive expressions: How should move(expr) interact with expressions like break, where the desugaring evaluates the expression at closure creation time?

Implementation history

• Initial implementation work: https://github.com/rust-lang/rust/pull/155023
• Coroutine closure support: https://github.com/rust-lang/rust/pull/157738
• Bugs: https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aopen%20label%3AF-move_expr%20label%3AC-bug

Read RFC 3968 and implementation PRs #155023 and #157738 first, then choose one unchecked area rather than treating this as a standalone task. Possible entry points mentioned are UI, borrowck, and nested-closure test coverage, documentation, or the style guide. Done means completing one focused checklist item and its relevant review or validation.