Skip to content

Failure to parse "value as Type[index]" #35813

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.

Sign up for GitHub

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

Jump to bottom
Closed
CensoredUsername opened this issue Aug 19, 2016 · 5 comments · Fixed by #68985
Closed

Failure to parse "value as Type[index]" #35813

CensoredUsername opened this issue Aug 19, 2016 · 5 comments · Fixed by #68985
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-parser Area: The lexing & parsing of Rust source code to an AST C-enhancement Category: An issue proposing an enhancement or a PR with one. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@CensoredUsername
Copy link
Contributor

Summary:

Parsing value as Type[index] leads to the error:

expected one of `!`, `(`, `::`, `;`, or `<`, found `[`

It is currently impossible for a cast expression to have a trailing index expression without surrounding the cast expression by parenthesis. This however seems to be a parser limitation, not a grammar limitation.

As currently the macro language guarantees that ty/path expressions can be followed by a "[", this seems like a bug in the parser to me, as it seems to be parsing it as value as (Type[index]) which makes no grammatical sense, compared to parsing it as (value as Type)[index] which should be valid if I read the lexical structure specification correctly.

rustc --version
>>> rustc 1.12.0-nightly (576f76659 2016-08-09)
@Aatch Aatch added the A-parser Area: The lexing & parsing of Rust source code to an AST label Aug 19, 2016
@oli-obk
Copy link
Contributor

oli-obk commented Aug 19, 2016

I think it's parsed correctly, but should get a tailored error message to suggest surrounding the cast with parens.

@CensoredUsername
Copy link
Contributor Author

Considering that a trailing "[" is never valid in the type syntax (otherwise macros break) and the fact that foo as Type * bar and variants are perfectly legal (even > which is another symbol that occurs in type syntax).

But if a tailored error message will be made instead, then this should also include other postfix operators like val as Type . attr which are currently rejected even though technically being legal by the lexical grammar specification. (another one is the proposed "?" operator)

@Mark-Simulacrum
Copy link
Member

This is still lacking a tailored error message, and as far as I know no movement has been made here.

@Mark-Simulacrum Mark-Simulacrum added the A-diagnostics Area: Messages for errors, warnings, and lints label May 11, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 26, 2017
@estebank estebank added E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 22, 2019
@daboross daboross mentioned this issue Feb 9, 2020
Merged
@daboross
Copy link
Contributor

daboross commented Feb 9, 2020

Submitted a pull request to fix this! #68985

Centril added a commit to Centril/rust that referenced this issue Mar 7, 2020
@Centril
Rollup merge of rust-lang#68985 - daboross:fix-35813, r=Centril
bb0959d 
Parse & reject postfix operators after casts

This adds an explicit error messages for when parsing `x as Type[0]` or similar expressions. Our add an extra parse case for parsing any postfix operator (dot, indexing, method calls, await) that triggers directly after parsing `as` expressions.

My friend and I worked on this together, but they're still deciding on a github username and thus I'm submitting this for both of us.

It will immediately error out, but will also provide the rest of the parser with a useful parse tree to deal with.

There's one decision we made in how this produces the parse tree. In the situation `&x as T[0]`, one could imagine this parsing as either `&((x as T)[0])` or `((&x) as T)[0]`. We chose the latter for ease of implementation, and as it seemed the most intuitive.

Feedback welcome! This is our first change to the parser section, and it might be completely horrible.

Fixes rust-lang#35813.
@bors bors closed this as completed in 111724f Mar 7, 2020
@CensoredUsername
Copy link
Contributor Author

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-parser Area: The lexing & parsing of Rust source code to an AST C-enhancement Category: An issue proposing an enhancement or a PR with one. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Parse & reject postfix operators after casts daboross/rust
6 participants
@oli-obk @Aatch @daboross @estebank @CensoredUsername @Mark-Simulacrum