diff options
| author | Dylan DPC <99973273+Dylan-DPC@users.noreply.github.com> | 2022-07-12 17:06:33 +0530 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-07-12 17:06:33 +0530 |
| commit | 9997c51496f3f56409f0ebad1cfe9b08b4815de0 (patch) | |
| tree | 5e9ac1f524e840e3f340dabc30b7c423bdcce500 /compiler/rustc_codegen_gcc | |
| parent | 76153661dc2375068f9f49ca63c76b97e284d429 (diff) | |
| parent | 1c3bab2fc9f9eb30c03b5019cb9503fef62e31a5 (diff) | |
| download | rust-9997c51496f3f56409f0ebad1cfe9b08b4815de0.tar.gz rust-9997c51496f3f56409f0ebad1cfe9b08b4815de0.zip | |
Rollup merge of #98633 - c410-f3r:yet-another-let-chain, r=estebank
Fix last `let_chains` blocker
In order to forbid things like `let x = (let y = 1);` or `if let a = 1 && { let x = let y = 1; } {}`, the parser **HAS** to know the context of `let`.
This context thing is not a surprise in the parser because you can see **a lot** of ad hoc fixes mixing parsing logic with validation logic creating code that looks more like spaghetti with tomato sauce.
To make things even greater, a new ad hoc fix was added to only allow `let`s in a valid `let_chains` context by checking the previously processed token. This was the only solution I could think of and believe me, I thought about it for a long time 👍
In the long term, it should be preferable to segregate different responsibilities or create a more robust and cleaner parser framework.
cc https://github.com/rust-lang/rust/pull/94927
cc https://github.com/rust-lang/rust/issues/53667
Diffstat (limited to 'compiler/rustc_codegen_gcc')
0 files changed, 0 insertions, 0 deletions
