diff options
| author | León Orell Valerian Liehr <me@fmease.dev> | 2025-05-18 18:44:11 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-05-18 18:44:11 +0200 |
| commit | 4e5b1aa055aa0a0003a0ab81fa3efef495a0c0c6 (patch) | |
| tree | 8ac85f354e11b44a29ccc0fc0c57b37af7459388 /compiler/rustc_codegen_gcc/src/errors.rs | |
| parent | 6f415e0f4c547c40490d1eeac971bd7b1057ac23 (diff) | |
| parent | f0b8ec1d71f055cbdb741565eaddabc93bf1ae75 (diff) | |
| download | rust-4e5b1aa055aa0a0003a0ab81fa3efef495a0c0c6.tar.gz rust-4e5b1aa055aa0a0003a0ab81fa3efef495a0c0c6.zip | |
Rollup merge of #140746 - dianne:guard-pat-res, r=oli-obk
name resolution for guard patterns This PR provides an initial implementation of name resolution for guard patterns [(RFC 3637)](https://github.com/rust-lang/rfcs/blob/master/text/3637-guard-patterns.md). This does not change the requirement that the bindings on either side of an or-pattern must be the same [(proposal here)](https://github.com/rust-lang/rfcs/blob/master/text/3637-guard-patterns.md#allowing-mismatching-bindings-when-possible); the code that handles that is separate from what this PR touches, so I'm saving it for a follow-up. On a technical level, this separates "collecting the bindings in a pattern" (which was already done for or-patterns) from "introducing those bindings into scope". I believe the approach used here can be extended straightforwardly in the future to work with `if let` guard patterns, but I haven't tried it myself since we don't allow those yet. Tracking issue for guard patterns: #129967 cc ``@Nadrieril``
Diffstat (limited to 'compiler/rustc_codegen_gcc/src/errors.rs')
0 files changed, 0 insertions, 0 deletions
