333388fd3c
There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
24 lines
496 B
Rust
24 lines
496 B
Rust
#![feature(let_chains)]
|
|
|
|
fn let_or_guard(x: Result<Option<i32>, ()>) {
|
|
match x {
|
|
Ok(opt) if let Some(4) = opt || false => {}
|
|
//~^ ERROR expected expression, found `let` statement
|
|
_ => {}
|
|
}
|
|
}
|
|
|
|
fn hiding_unsafe_mod(x: Result<Option<i32>, ()>) {
|
|
match x {
|
|
Ok(opt)
|
|
if {
|
|
unsafe mod a {};
|
|
//~^ ERROR module cannot be declared unsafe
|
|
false
|
|
} => {}
|
|
_ => {}
|
|
}
|
|
}
|
|
|
|
fn main() {}
|