Skip to content
This repository has been archived by the owner on Apr 8, 2024. It is now read-only.

How to handle brace expression restrictions? #53

Open
ehuss opened this issue Jun 28, 2019 · 3 comments
Open

How to handle brace expression restrictions? #53

ehuss opened this issue Jun 28, 2019 · 3 comments
Labels
grammar Issues with the definition of the rust grammar restrictions Issues related to the permissiveness of the grammar

Comments

@ehuss
Copy link
Contributor

ehuss commented Jun 28, 2019

Various places do not allow struct expressions. All of the following fail to parse in libsyntax, but pass in the current lyg grammar:

if S{a:1} {}
if let x=S{a:1} {}
while S{a:1} {}
while let x=S{a:1} {}
for pat in S{a:1} {}
match S{a:1} {}

This restriction applies recursively (I'm not sure how to express this), that is the following is also rejected:

if x==S{a:1} {}

if S{a:1}.foo() {}

I included a field just because rustc will give a helpful suggestion, whereas a fieldless expression gets confused by the second {} which rustc just treats an independent block, as this hilarious example shows:

#[derive(PartialEq)]
struct S;
let x = S;
if x != S{} {
    // This block is executed because it is not part of the `if` expression, 
    // even though it appears to be. 
    println!("hm, x!=S{} should be false");
}

Should this kind of ambiguity rejection be part of the syntax?

See rust-lang/rust#59981 for some examples, and where this was recently changed. See also rust-lang/reference#569.

@ehuss ehuss added the grammar Issues with the definition of the rust grammar label Jun 28, 2019
@CAD97
Copy link
Contributor

CAD97 commented Jun 28, 2019

For the if x != S{} { /* block */ } version, this has to parse the way it currently does, to allow the perfectly legal and normal code of comparing two variables in a condition. Here we just have to lean on rustfmt formatting, I guess.

@ehuss
Copy link
Contributor Author

ehuss commented Jun 28, 2019

Oh, I'm not implying it is wrong for libsyntax to interpret it the way it does. Although a warning might be nice, this is a contrived example that I doubt anyone would ever write.

I'm more trying to understand how the grammar can be written to express this behavior. libsyntax uses "restrictions", and in #13 (comment) @eddyb mentioned the open question of how to handle this. #39 is another example where restrictions need to be expressed.

Is it on the table for the GLL parser to be able to express these directly? If not, then it seems you have to bifurcate the definitions (ExprNoStruct would have all expressions except Struct, but that would require recursively copying all the expressions, which I think would be terrible).

What are the options for handling these kinds of restrictions?

@Centril
Copy link
Contributor

Centril commented Jun 28, 2019

I think rust-lang/gll#27 could be a way to handle it with "flags".

I did something similar in the specification of or-patterns, https://github.com/rust-lang/rfcs/blob/master/text/2535-or-patterns.md#grammar.

@eddyb eddyb added restrictions Issues related to the permissiveness of the grammar and removed restrictions Issues related to the permissiveness of the grammar labels Jul 1, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
grammar Issues with the definition of the rust grammar restrictions Issues related to the permissiveness of the grammar
Projects
None yet
Development

No branches or pull requests

4 participants