Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Identifiers in range notation are not parsed correctly #20830

Closed
milibopp opened this issue Jan 9, 2015 · 5 comments
Closed

Identifiers in range notation are not parsed correctly #20830

milibopp opened this issue Jan 9, 2015 · 5 comments

Comments

@milibopp
Copy link
Contributor

milibopp commented Jan 9, 2015

The following example fails to compile currently:

let a = 3;
for i in 0..a {
    let b = i;
}

with

<anon>:4:9: 4:12 error: expected identifier, found keyword `let`
<anon>:4         let b = i;
                 ^~~
<anon>:4:13: 4:14 error: expected `:`, found `b`
<anon>:4         let b = i;
@alexcrichton
Copy link
Member

cc @nick29581

@milibopp
Copy link
Contributor Author

milibopp commented Jan 9, 2015

btw replacing 0..a with (0..a) or 0..(a) makes the compiler behave correctly.

milibopp added a commit to milibopp/nalgebra that referenced this issue Jan 9, 2015
There is an issue in the compiler that makes some workaround necessary here,
see rust-lang/rust#20830
@milibopp
Copy link
Contributor Author

milibopp commented Jan 9, 2015

Maybe this sheds some more light on it:

let a = 3;
for i in 0..a {}

Apparently the compiler parses it as for i in 0..(a {}) interpreting a {} as a structure literal.

Error:

<anon>:3:19: 3:20 error: structure literal must either have at least one field or use functional structure update syntax
<anon>:3     for i in 0..a {}
                           ^
<anon>:4:1: 4:2 error: expected `{`, found `}`
<anon>:4 }
         ^
<anon>:4:1: 4:2 help: place this code inside a block
<anon>:4 }
         ^

@dgrunwald
Copy link
Contributor

Looks like the parser is replacing the restrictions with RESTRICTION_NO_DOTS when parsing the RHS of the range notation, thus deleting the RESTRICTION_NO_STRUCT_LITERAL. It should add to the existing restrictions instead of replacing them.

@huonw
Copy link
Member

huonw commented Jan 10, 2015

Closing as a dupe of #20241.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants