Make closure capturing have consistent and correct behaviour around patterns
Reference PR:
- https://github.com/rust-lang/reference/pull/1837
This PR has two goals:
- firstly, it fixesrust-lang/rust#137467. In order to do so, it needs to introduce a small breaking change surrounding the interaction of closure captures with matching against enums with uninhabited variants. Yes – to fix an ICE!
- this also fixesrust-lang/rust#138973, a slightly different case with the same root cause.
- likewise, fixesrust-lang/rust#140011.
- secondly, it fixesrust-lang/rust#137553, making the closure capturing rules consistent between `let` patterns and `match` patterns. This is new insta-stable behavior.
## Background
This change concerns how precise closure captures interact with patterns. As a little known feature, patterns that require inspecting only part of a value will only cause that part of the value to get captured:
```rust
fn main() {
let mut a = (21, 37);
// only captures a.0, writing to a.1 does not invalidate the closure
let mut f = || {
let (ref mut x, _) = a;
*x = 42;
};
a.1 = 69;
f();
}
```
I was not able to find any discussion of this behavior being introduced, or discussion of its edge-cases, but it is [documented in the Rust reference](https://doc.rust-lang.org/reference/types/closure.html#r-type.closure.capture.precision.wildcard).
The currently stable behavior is as follows:
- if any pattern contains a binding, the place it binds gets captured (implemented in current `walk_pat`)
- patterns in refutable positions (`match`, `if let`, `let ... else`, but not destructuring `let` or destructuring function parameters) get processed as follows (`maybe_read_scrutinee`):
- if matching against the pattern will at any point require inspecting a discriminant, or it includes a variable binding not followed by an ``@`-pattern,` capture *the entire scrutinee* by reference
You will note that this behavior is quite weird and it's hard to imagine a sensible rationale for at least some of its aspects. It has the following issues:
- firstly, it assumes that matching against an irrefutable pattern cannot possibly require inspecting any discriminants. With or-patterns, this isn't true, and it is the cause of the rust-lang/rust#137467 ICE.
- secondly, the presence of an ``@`-pattern` doesn't really have any semantics by itself. This is the weird behavior tracked as rust-lang/rust#137553.
- thirdly, the behavior is different between pattern-matching done through `let` and pattern-matching done through `match` – which is a superficial syntactic difference
This PR aims to address all of the above issues. The new behavior is as follows:
- like before, if a pattern contains a binding, the place it binds gets captured as required by the binding mode
- if matching against the pattern requires inspecting a disciminant, the place whose discriminant needs to be inspected gets captured by reference
"requires inspecting a discriminant" is also used here to mean "compare something with a constant" and other such decisions. For types other than ADTs, the details are not interesting and aren't changing.
## The breaking change
During closure capture analysis, matching an `enum` against a constructor is considered to require inspecting a discriminant if the `enum` has more than one variant. Notably, this is the case even if all the other variants happen to be uninhabited. This is motivated by implementation difficulties involved in querying whether types are inhabited before we're done with type inference – without moving mountains to make it happen, you hit this assert: https://github.com/rust-lang/rust/blob/43f0014ef0f242418674f49052ed39b70f73bc1c/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L121
Now, because the previous implementation did not concern itself with capturing the discriminants for irrefutable patterns at all, this is a breaking change – the following example, adapted from the testsuite, compiles on current stable, but will not compile with this PR:
```rust
#[derive(Clone, Copy, PartialEq, Eq, Debug)]
enum Void {}
pub fn main() {
let mut r = Result::<Void, (u32, u32)>::Err((0, 0));
let mut f = || {
let Err((ref mut a, _)) = r;
*a = 1;
};
let mut g = || {
//~^ ERROR: cannot borrow `r` as mutable more than once at a time
let Err((_, ref mut b)) = r;
*b = 2;
};
f();
g();
assert_eq!(r, Err((1, 2)));
}
```
## Is the breaking change necessary?
One other option would be to double down, and introduce a set of syntactic rules for determining whether a sub-pattern is in an irrefutable position, instead of querying the types and checking how many variants there are.
**This would not eliminate the breaking change,** but it would limit it to more contrived examples, such as
```rust
let ((true, Err((ref mut a, _, _))) | (false, Err((_, ref mut a, _)))) = x;
```
In this example, the `Err`s would not be considered in an irrefutable position, because they are part of an or-pattern. However, current stable would treat this just like a tuple `(bool, (T, U, _))`.
While introducing such a distinction would limit the impact, I would say that the added complexity would not be commensurate with the benefit it introduces.
## The new insta-stable behavior
If a pattern in a `match` expression or similar has parts it will never read, this part will not be captured anymore:
```rust
fn main() {
let mut a = (21, 37);
// now only captures a.0, instead of the whole a
let mut f = || {
match a {
(ref mut x, _) => *x = 42,
}
};
a.1 = 69;
f();
}
```
Note that this behavior was pretty much already present, but only accessible with this One Weird Trick™:
```rust
fn main() {
let mut a = (21, 37);
// both stable and this PR only capture a.0, because of the no-op `@-pattern`
let mut f = || {
match a {
(ref mut x @ _, _) => *x = 42,
}
};
a.1 = 69;
f();
}
```
## The second, more practically-relevant breaking change
After running crater, we have discovered that the aforementioned insta-stable behavior, where sometimes closures will now capture less, can also manifest as a breaking change. This is because it is possible that previously a closure would capture an entire struct by-move, and now it'll start capturing only part of it – some by move, and some by reference. This then causes the closure to have a more restrictive lifetime than it did previously.
See:
- https://github.com/rust-lang/rust/pull/138961#issuecomment-2761888557
- https://github.com/EC-labs/cec-assignment/pull/1
- https://github.com/tryandromeda/andromeda/pull/43
## Implementation notes
The PR has two main commits:
- "ExprUseVisitor: properly report discriminant reads" makes `walk_pat` perform all necessary capturing. This is the part that fixesrust-lang/rust#137467.
- "ExprUseVisitor: remove maybe_read_scrutinee" removes the unnecessary "capture the entire scrutinee" behavior, fixing rust-lang/rust#137553.
The new logic stops making the distinction between one particular example that used to work, and another ICE, tracked as rust-lang/rust#119786. As this requires an unstable feature, I am leaving this as future work.
[rustdoc] Fix invalid handling of field followed by negated macro call
This is the bug uncovered in https://github.com/rust-lang/rust/pull/150022. Once fixed Ill rebuild all compiler docs and see if we can enable the option for compiler docs. =D
It's a weird case where we extracted some tokens out of the iterator and then, when checking next items (from this iterator), it didn't find the `:` token, and therefore badly assumed the token kind.
The solution I came up with is to instead not extract tokens from the iterator and to count how many tokens are in the current path. So when iterate over the items, instead of having a mix of extracted tokens and tokens still inside the iterator, we now only iterate over the iterator.
The biggest change here is that `get_full_ident_path` will return an option instead of a `Vec`, and if it's contains `:` (one, not two), then it will return `None` and the `:` will be handled like any token and not like a path (which is more correct imo).
r? `@yotamofek`
miri: add `miri_spin_loop` to make `hint::spin_loop` work consistently
fixes https://github.com/rust-lang/rust/issues/150050
Always use the same implementation when running miri (regardless of target, for consistency). This implementation yields the current thread to try find actual bugs.
r? RalfJung
Partially revert #147888 and print warning if LLVM CMake dir is missing when building Enzyme
Partially reverts https://github.com/rust-lang/rust/pull/147888, Enzyme cannot be build with `download-ci-llvm = true`.
r? ``@ZuseZ4``
Port `#[rustc_legacy_const_generics]` to use attribute parser
Small PR that ports the `#[rustc_legacy_const_generics]` to use the new attribute parser!
r? JonathanBrouwer
Use annotate-snippet as default emitter on stable
This is implementation of https://github.com/rust-lang/rust/issues/149932
Now, after MCP was accepted, we can use annotate-snippet as default emitter for errors, that means that we not longer need of previous emitter, so this PR removed previous emitter and makes annotate-snippet new default one both on stable and nightly
(this PR does not remove a code of previous emitter it just removes a `Default` option of `HumanReadableErrorType` enum, and keeping only `HumanReadableErrorType::AnnotateSnippet` as it now uses by default)
Update books
## rust-lang/nomicon
1 commits in 9fe8fa599ad228dda74f240cc32b54bc5c1aa3e6..5b3a9d084cbc64e54da87e3eec7c7faae0e48ba9
2025-12-12 12:24:05 UTC to 2025-12-12 12:24:05 UTC
- Update method lookup link in dot-operator.md (rust-lang/nomicon#513)
## rust-lang/reference
4 commits in 50c5de90487b68d429a30cc9466dc8f5b410128f..ec78de0ffe2f8344bd0e222b17ac7a7d32dc7a26
2025-12-15 16:17:43 UTC to 2025-12-15 16:15:06 UTC
- tokens: clarify in escape tables that digits are hex (rust-lang/reference#2105)
- tokens: remove misplaced ".token." within a word (rust-lang/reference#2106)
- macros-by-example: add space in `macro.decl.repetition.fragment` example (rust-lang/reference#2107)
- Fix restrictions of or-patterns (rust-lang/reference#2108)
Add new Tier-3 target: riscv64im-unknown-none-elf
This PR proposes to add riscv64im-unknown-none-elf, a subset of the already supported riscv64imac-unknown-none-elf.
The motivation behind this PR is that we want to standardize (most) zkVMs on riscv64im-none and riscv64ima-none. Having different variants of riscv extensions, also seems to be within expectation, atleast with respects to riscv32.
Note: This does not mean that we will be able to remove [riscv32im-risc0-zkvm-elf](https://doc.rust-lang.org/rustc/platform-support/riscv32im-risc0-zkvm-elf.html) -- I am not aware of all of the dependents for this
**Tier-3 Policy**
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
I assigned Rust Embedded Working Group, since they are already maintaining riscv64IMAC, though I am happy to assign myself.
> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
It follows the naming convention of the other bare metal riscv targets
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
This has the same requirements as riscv{32, 64}imac
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via ````@)```` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target. (Having support in a fork of the backend is not sufficient, it must be upstream.)
Acknowledging the above.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#149744 (test: update duplicate many_digits test to use f64 instead of f32)
- rust-lang/rust#149946 (mir_build: Move and rename code for partitioning match candidates)
- rust-lang/rust#149987 (Move ambient cdb discovery from compiletest to bootstrap)
- rust-lang/rust#149990 (Improve amdgpu docs: Mention device-libs and xnack)
- rust-lang/rust#149994 (Allow vector types for amdgpu)
- rust-lang/rust#149997 (Link POSIX instead of Linux manual for Instant)
- rust-lang/rust#150010 (Correct library linking for hexagon targets in run-make tests)
r? `@ghost`
`@rustbot` modify labels: rollup
Correct library linking for hexagon targets in run-make tests
Fixes the run-make test framework to use target-specific library linking instead of host-based detection. Previously, tests for hexagon targets failed because the framework used uname() to detect libraries to link, which returned Linux libraries (-lm -lrt -ldl -lpthread) that don't exist on all hexagon targets.
- Use target() instead of uname() to detect cross-compilation targets
- Add hexagon-specific library configuration (-lunwind -lclang_rt.builtins-hexagon)
- Maintain backward compatibility for host-native compilation
This enables hexagon tests to compile and link successfully with the appropriate runtime libraries for the hexagon platform.
Improve amdgpu docs: Mention device-libs and xnack
Mention amdgpu-device-libs for allocator and println support and mention the necessary target flag for GPUs from some some series without xnack support.
For the last half year, there were no major changes in the amdgpu-device-libs crate (in fact, there was no need to update the crate), so I believe it is stable enough to mention it here.
The xnack-support flag is something I stumbled upon recently, when more complex printlns failed on a certain GPU.
Tracking issue: rust-lang/rust#135024
Move ambient cdb discovery from compiletest to bootstrap
- Follow-up to https://github.com/rust-lang/rust/pull/149710
---
As with the previous PR, this PR takes the compiletest code for discovering an “ambient” `cdb` in the user's path, and moves it to bootstrap.
The discovery code is indeed questionable, but improving it is out of scope for this PR.
r? jieyouxu
Guillaume Gomez