Field access of block: discrepancy between parser-lalr and rustc

[rprichard]

struct S { f: u32 }
fn main() {
    { S { f: 42 } }.f; // rustc accepts, parser-lalr rejects
    { 42 } as i32; // rustc and parser-lalr reject
    { 42 } == 42; // rustc and parser-lalr reject
}

The grammar in src/grammar/parser-lalr.y should probably be relaxed to accept the first example.

AFAIK, Rust could allow the other two cases (and others), because there are no statements or expressions that begin with as or ==.

[steveklabnik]

/cc @rust-lang/lang , is this grammar correct or just incidental?

(tagging with lang until I know what they want, and I'll document that.)

[nikomatsakis]

Hmm, interesting question! I think the reference grammar is correct here, and rustc is not working properly. The rule is that "statement-like" expressions cannot take part in binary expressions; I think that should include the . operator. I think that the code incorrectly permits block expressions to be used with the "suffix" operators (., [], ()). But there are some weird edge cases too:

For example, this fails to compile:

fn foo(x: u32) { }
fn main() {
  let f = foo;
  { f } (22)
}

but the error it gives me is surprising:

<anon>:4:5: 4:6 error: mismatched types:
 expected `()`,
    found `fn(u32) {foo}`
(expected (),
    found fn item) [E0308]
<anon>:4   { f } (22);
             ^
<anon>:4:5: 4:6 help: see the detailed explanation for E0308
error: aborting due to previous error
playpen: application terminated with error code 101

[rprichard]

If {1} is a statement-like expression, then it can appear in a binary expression. This is accepted by rustc and parser-lalr:

fn main() {
  1 == {1};
  1 == ({1} + {1});
}

As the LALR grammar describes it, a semicolon-terminated expression statement is a nonblock_expr non-terminal. A nonblock_expr can be a binary operation, and the LHS must also be a nonblock_expr, whereas the RHS can be an arbitrary expr. I can't think of a nicer way to describe the rule at the moment.

Both parsers reject this:

fn main() {
  {1} == 1;
}

I discovered an interesting case, though:

fn main() {
  let x = { 1 + {2} * {3} };
  println!("{}", x);
}

This code parses and compiles, but the two parsers disagree on what it should output.

rustc says 9, indicating a parse tree of (1 + 2) * 3.
parser-lalr -v instead parses it as expected, 1 + (2 * 3):

|   |   |   |   |   |   |   (ExprBlock
|   |   |   |   |   |   |   |   (ExprBinary
|   |   |   |   |   |   |   |   |   BiAdd
|   |   |   |   |   |   |   |   |   (ExprLit
|   |   |   |   |   |   |   |   |   |   (LitInteger
|   |   |   |   |   |   |   |   |   |   |   1
|   |   |   |   |   |   |   |   |   |   )
|   |   |   |   |   |   |   |   |   )
|   |   |   |   |   |   |   |   |   (ExprBinary
|   |   |   |   |   |   |   |   |   |   BiMul
|   |   |   |   |   |   |   |   |   |   (ExprBlock
|   |   |   |   |   |   |   |   |   |   |   (ExprLit
|   |   |   |   |   |   |   |   |   |   |   |   (LitInteger
|   |   |   |   |   |   |   |   |   |   |   |   |   2
|   |   |   |   |   |   |   |   |   |   |   |   )
|   |   |   |   |   |   |   |   |   |   |   )
|   |   |   |   |   |   |   |   |   |   )
|   |   |   |   |   |   |   |   |   |   (ExprBlock
|   |   |   |   |   |   |   |   |   |   |   (ExprLit
|   |   |   |   |   |   |   |   |   |   |   |   (LitInteger
|   |   |   |   |   |   |   |   |   |   |   |   |   3
|   |   |   |   |   |   |   |   |   |   |   |   )
|   |   |   |   |   |   |   |   |   |   |   )
|   |   |   |   |   |   |   |   |   |   )
|   |   |   |   |   |   |   |   |   )
|   |   |   |   |   |   |   |   )
|   |   |   |   |   |   |   )

If I remove the unnecessary block around the expression, rustc prints 7 as expected:

fn main() {
  let x = 1 + {2} * {3};  // removed the unnecessary block here
  println!("{}", x);
}

[rprichard]

I split off the operator precedence issue to #28777.

[nikomatsakis]

Let me be more precise. It cannot START a binary operator, when in
statement position. There is a big difference between "{1} + 2" and "1 +
{2}", in other words.

On Wed, Sep 30, 2015 at 4:45 PM, Ryan Prichard notifications@github.com
wrote:

If {1} is a statement-like expression, then it can appear in a binary
expression. This is accepted by rustc and parser-lalr:

fn main() {
1 == {1};
1 == ({1} + {1});
}

As the LALR grammar describes it, a semicolon-terminated expression
statement is a nonblock_expr non-terminal. A nonblock_expr can be a
binary operation, and the LHS must also be a nonblock_expr, whereas the
RHS can be an arbitrary expr. I can't think of a nicer way to describe
the rule at the moment.

Both parsers reject this:

fn main() {
{1} == 1;
}

I discovered an interesting case, though:

fn main() {
let x = { 1 + {2} * {3} };
println!("{}", x);
}

This code parses and compiles, but the two parsers disagree on what it
should output.

rustc says 9, indicating a parse tree of (1 + 2) * 3.
parser-lalr -v instead parses it as expected, 1 + (2 * 3):

| | | | | | | (ExprBlock
| | | | | | | | (ExprBinary
| | | | | | | | | BiAdd
| | | | | | | | | (ExprLit
| | | | | | | | | | (LitInteger
| | | | | | | | | | | 1
| | | | | | | | | | )
| | | | | | | | | )
| | | | | | | | | (ExprBinary
| | | | | | | | | | BiMul
| | | | | | | | | | (ExprBlock
| | | | | | | | | | | (ExprLit
| | | | | | | | | | | | (LitInteger
| | | | | | | | | | | | | 2
| | | | | | | | | | | | )
| | | | | | | | | | | )
| | | | | | | | | | )
| | | | | | | | | | (ExprBlock
| | | | | | | | | | | (ExprLit
| | | | | | | | | | | | (LitInteger
| | | | | | | | | | | | | 3
| | | | | | | | | | | | )
| | | | | | | | | | | )
| | | | | | | | | | )
| | | | | | | | | )
| | | | | | | | )
| | | | | | | )

If I remove the unnecessary block around the expression, rustc prints 7
as expected:

fn main() {
let x = 1 + {2} * {3}; // removed the unnecessary block here
println!("{}", x);
}

—
Reply to this email directly or view it on GitHub
#28379 (comment).

[nikomatsakis]

In any case, this all feels like good motivation for me to try and get some
version of parser-lalr running in LALRPOP :)

On Wed, Sep 30, 2015 at 5:05 PM, Nicholas Matsakis nmatsakis@mozilla.com
wrote:

Let me be more precise. It cannot START a binary operator, when in
statement position. There is a big difference between "{1} + 2" and "1 +
{2}", in other words.

On Wed, Sep 30, 2015 at 4:45 PM, Ryan Prichard notifications@github.com
wrote:

If {1} is a statement-like expression, then it can appear in a binary
expression. This is accepted by rustc and parser-lalr:

fn main() {
1 == {1};
1 == ({1} + {1});
}

As the LALR grammar describes it, a semicolon-terminated expression
statement is a nonblock_expr non-terminal. A nonblock_expr can be a
binary operation, and the LHS must also be a nonblock_expr, whereas the
RHS can be an arbitrary expr. I can't think of a nicer way to describe
the rule at the moment.

Both parsers reject this:

fn main() {
{1} == 1;
}

I discovered an interesting case, though:

fn main() {
let x = { 1 + {2} * {3} };
println!("{}", x);
}

This code parses and compiles, but the two parsers disagree on what it
should output.

rustc says 9, indicating a parse tree of (1 + 2) * 3.
parser-lalr -v instead parses it as expected, 1 + (2 * 3):

| | | | | | | (ExprBlock
| | | | | | | | (ExprBinary
| | | | | | | | | BiAdd
| | | | | | | | | (ExprLit
| | | | | | | | | | (LitInteger
| | | | | | | | | | | 1
| | | | | | | | | | )
| | | | | | | | | )
| | | | | | | | | (ExprBinary
| | | | | | | | | | BiMul
| | | | | | | | | | (ExprBlock
| | | | | | | | | | | (ExprLit
| | | | | | | | | | | | (LitInteger
| | | | | | | | | | | | | 2
| | | | | | | | | | | | )
| | | | | | | | | | | )
| | | | | | | | | | )
| | | | | | | | | | (ExprBlock
| | | | | | | | | | | (ExprLit
| | | | | | | | | | | | (LitInteger
| | | | | | | | | | | | | 3
| | | | | | | | | | | | )
| | | | | | | | | | | )
| | | | | | | | | | )
| | | | | | | | | )
| | | | | | | | )
| | | | | | | )

If I remove the unnecessary block around the expression, rustc prints 7
as expected:

fn main() {
let x = 1 + {2} * {3}; // removed the unnecessary block here
println!("{}", x);
}

—
Reply to this email directly or view it on GitHub
#28379 (comment).

[nikomatsakis]

Nominating for discussion. Related to #28785

[nikomatsakis]

I just realized why that example I gave of {f} (22) is giving me the type error. It's the rule which says that a brace-expression, when used as a statement, must have type unit. Precisely to prevent this sort of confusion!

[nikomatsakis]

triage: P-medium

This is a backwards incompat issue, but feels like an edge case. Nonetheless we should definitely fix it!