Rollup merge of #60188 - estebank:recover-block, r=varkor
Identify when a stmt could have been parsed as an expr There are some expressions that can be parsed as a statement without a trailing semicolon depending on the context, which can lead to confusing errors due to the same looking code being accepted in some places and not others. Identify these cases and suggest enclosing in parenthesis making the parse non-ambiguous without changing the accepted grammar. Fix #54186, cc #54482, fix #59975, fix #47287.
This commit is contained in:
@@ -207,6 +207,31 @@ impl AssocOp {
|
||||
ObsoleteInPlace | Assign | AssignOp(_) | As | DotDot | DotDotEq | Colon => None
|
||||
}
|
||||
}
|
||||
|
||||
/// This operator could be used to follow a block unambiguously.
|
||||
///
|
||||
/// This is used for error recovery at the moment, providing a suggestion to wrap blocks with
|
||||
/// parentheses while having a high degree of confidence on the correctness of the suggestion.
|
||||
pub fn can_continue_expr_unambiguously(&self) -> bool {
|
||||
use AssocOp::*;
|
||||
match self {
|
||||
BitXor | // `{ 42 } ^ 3`
|
||||
Assign | // `{ 42 } = { 42 }`
|
||||
Divide | // `{ 42 } / 42`
|
||||
Modulus | // `{ 42 } % 2`
|
||||
ShiftRight | // `{ 42 } >> 2`
|
||||
LessEqual | // `{ 42 } <= 3`
|
||||
Greater | // `{ 42 } > 3`
|
||||
GreaterEqual | // `{ 42 } >= 3`
|
||||
AssignOp(_) | // `{ 42 } +=`
|
||||
LAnd | // `{ 42 } &&foo`
|
||||
As | // `{ 42 } as usize`
|
||||
// Equal | // `{ 42 } == { 42 }` Accepting these here would regress incorrect
|
||||
// NotEqual | // `{ 42 } != { 42 } struct literals parser recovery.
|
||||
Colon => true, // `{ 42 }: usize`
|
||||
_ => false,
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
pub const PREC_RESET: i8 = -100;
|
||||
|
||||
Reference in New Issue
Block a user