Failure to parse "value as Type[index]" #35813
Comments
|
I think it's parsed correctly, but should get a tailored error message to suggest surrounding the cast with parens. |
|
Considering that a trailing "[" is never valid in the type syntax (otherwise macros break) and the fact that But if a tailored error message will be made instead, then this should also include other postfix operators like |
|
This is still lacking a tailored error message, and as far as I know no movement has been made here. |
Mark-Simulacrum
added
the
A-diagnostics
Mark-Simulacrum
added
the
C-enhancement
estebank
added
E-easy
|
Submitted a pull request to fix this! #68985 |
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.
|
Thanks! |
Summary:
Parsing
value as Type[index]leads to the error: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.The text was updated successfully, but these errors were encountered: