Repository navigation
Wrapping expr in curly braces changes the operator precedence #28777
Description
This program prints different values depending upon whether the v1 or v2 initializer is surrounded by curly braces:
fn main() {
let v1 = { 1 + {2} * {3} }; // 9, indicating a parse of (1 + 2) * 3
let v2 = 1 + {2} * {3} ; // 7, indicating a parse of 1 + (2 * 3)
println!("{}", v1);
println!("{}", v2);
}I think it should print 7 for both lines. parser-lalr -v accepts this program and consistently parses 1 + (2 * 3) for both lines.
| | | | | | | (ExprBlock
| | | | | | | | (ExprBinary
| | | | | | | | | BiAdd
| | | | | | | | | (ExprLit
| | | | | | | | | | (LitInteger
| | | | | | | | | | | 1
| | | | | | | | | | )
| | | | | | | | | )
| | | | | | | | | (ExprBinary
| | | | | | | | | | BiMul
| | | | | | | | | | (ExprBlock
| | | | | | | | | | | (ExprLit
| | | | | | | | | | | | (LitInteger
| | | | | | | | | | | | | 2
| | | | | | | | | | | | )
| | | | | | | | | | | )
| | | | | | | | | | )
| | | | | | | | | | (ExprBlock
| | | | | | | | | | | (ExprLit
| | | | | | | | | | | | (LitInteger
| | | | | | | | | | | | | 3
| | | | | | | | | | | | )
| | | | | | | | | | | )
| | | | | | | | | | )
| | | | | | | | | )
| | | | | | | | )
| | | | | | | )
Activity
[-]Operator precedence problem with `nonblock_expr`[/-][+]Wrapping expr in curly braces changes the operator precedence[/+]steveklabnik commentedon Oct 4, 2015
/cc @rust-lang/lang , I'm assuming this is not intended behavior.
nikomatsakis commentedon Oct 6, 2015
Um, I agree.
triage: P-medium
aaronkeen commentedon Dec 3, 2015
In looking at this issue, the incorrect parse (the initializer for v1 in the example, though this occurs in an assignment as well) stems from the path to parse_assoc_expr_with from parse_block_expr (passing through, of note, parse_stmt_). In parse_stmt_, parse_expr_res is invoked with RESTRICTION_STMT_EXPR. This ultimately results in the expr_is_complete check (in parse_assoc_expr_with) succeeding for '{2}' which prevents matching the '*' token and, thus, building the expected right subtree.
I am new to this codebase (and, for the most part, this language), so I am sill looking into the 'expr_is_complete' aspect of this portion of the parser.
pnkfelix commentedon Dec 3, 2015
uh wow; I was going to ask if this is related to #15300 , but this seems much worse than that to my eye...
aaronkeen commentedon Dec 4, 2015
As the comment in parser.rs alludes to in regards to semi-statements, this issue is related to #29071.
The outermost braces trigger a flag to check for expressions that do not require a semicolon to in order to be considered statements (e.g., if). If such an expression is found, then the parsing of associative expressions is terminated before consuming the next operator. This occurs in the original examples after the '{2}' because the block does not require a semicolon to be considered a statement.
For instance, the following illustrates the same parsing issue as the original example.
Removing the addition operator in the first expression results in a parse but with a typing error (to an extent further illustrating that the semi-statement is being considered a statement here; the same is true of the original binding for v1, but falling out of the recursion grabs the '* {3}').
I see that this all really goes back to #28379 (from which this issue was split) wherein @nikomatsakis states that a statement expression cannot start a binary expression when in statement position. The restriction flag makes it such that in '{ 1 + {2} * 3 }' it looks like '{2}' is in statement position for the subexpression '{2} * 3' (but it would not be considered as such if the original expression were '{ 1 + {2} + 3 }' because it appears as the right-operand of the first + instead of the left-operand of the *).
If the intent is that the start of a binary expression cannot be a statement-expression, but subsequent subexpressions can be, then it may be sufficient to remove the restriction when parsing the rhs (i.e., after an operator is accepted). Doing so in the original example given corrects the parsing (precedence) issue. The tests are still running to check for introduced failures.
aaronkeen commentedon Dec 4, 2015
The proposed change results in parse-fail/assoc-oddities-3.rs successfully parsing. It is unclear to me why it shouldn't. Back to looking through the intended grammar.
Corrects issue rust-lang#28777 by removing, once a binary operator is…
aaronkeen commentedon Dec 14, 2015
parse-fail/assoc-oddities-3.rs is successfully parsed by grammar/parser-lalr as well, so the proposed modification is consistent in this regard.
Rollup merge of rust-lang#30375 - aaronkeen:issue_28777, r=eddyb
jseyfried commentedon Feb 10, 2016
@eddyb This can be closed -- #30375 fixed it and added a test.
Adjust `assoc-oddities-3.rs`
Adjust `assoc-oddities-3.rs`