about summary refs log tree commit diff
path: root/compiler/rustc_codegen_gcc
diff options
context:
space:
mode:
authorDylan DPC <99973273+Dylan-DPC@users.noreply.github.com>2022-07-12 17:06:33 +0530
committerGitHub <noreply@github.com>2022-07-12 17:06:33 +0530
commit9997c51496f3f56409f0ebad1cfe9b08b4815de0 (patch)
tree5e9ac1f524e840e3f340dabc30b7c423bdcce500 /compiler/rustc_codegen_gcc
parent76153661dc2375068f9f49ca63c76b97e284d429 (diff)
parent1c3bab2fc9f9eb30c03b5019cb9503fef62e31a5 (diff)
downloadrust-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