-
Notifications
You must be signed in to change notification settings - Fork 242
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
[BUG] Parsing bug when multiplying a negative number #1068
Comments
I'll take a look at this issue. |
Sorry for the late response, and thank you for the reporting this bug. Not sure if you could already tell, but essentially we're parsing the first expression as a dereference of '1' minus '1' which is not correct. The reason the next line doesn't have the same mistake is because the parser has a specific rule for disallowing a postfix star to be treated as a dereference if followed by a left parenthesis as below: Line 5798 in d09b052
The reason it works in version 0.7.0 but not head is because of commit 5663493 which was published shortly after the release. @hsutter From what I can tell, in order to fix this issue we would need to change the parser behavior (which would break the code that prompted the original commit). We can't just add: MINUS LITERAL to the list of token(s) that can't follow a unary star, because even though it would fix this specific issue, that rule would prevent valid binary expressions involving a dereference, and it would also require EXCLAIM+ LITERAL to be added to the list of prohibited successor token(s) which would introduce an unbounded lookahead since any amount of exclaims can follow in each other in sequence. Curious what you think the best course of action is, since it seems we will need to change the language's behavior. |
Edited to add: I think the following may also address the way the first line parses, because then like the second line it will see interpreting it as a postfix operator doesn't work and backtrack and try multiplication? Need to try it. Thanks! I'm just in the middle of another bit where I'm not in a compilable state, but I would try this in parse.h:5798 (this is notes for myself, or in case someone wants to try it feel free): - // * and & can't be unary operators if followed by a (, identifier, or literal
+ // * and & can't be unary operators if followed by a (, identifier, prefix operator, or literal
if (
(
curr().type() == lexeme::Multiply
|| curr().type() == lexeme::Ampersand
)
&& peek(1)
&& (
peek(1)->type() == lexeme::LeftParen
|| peek(1)->type() == lexeme::Identifier
|| is_literal(peek(1)->type())
+ || is_prefix_operator(*peek(1))
)
)
{
break;
} |
Thanks @hsutter. So, the change you propose does indeed fix this issue, but as I suspected:
it introduces another issue. Consider the following code:
this now translates to
whereas before it would translate correctly. |
Ah, good point. I'll think about this more. Thanks again for the report and the notes! |
got another example (beside #1216) that breaks on current master:
|
Thank you for the report. |
Describe the bug
Multiplying by a negative number is being parsed incorrectly. Putting the negative number in parenthesis is a workaround to parse it correctly.
To Reproduce
This cpp2 code:
Compiles to this cpp code
https://godbolt.org/z/KMc6sxoPe
Additional context
This is present in the head, but not in the release 0.7.0
The text was updated successfully, but these errors were encountered: