Fixes parsing of signed numeric literals #1484
Conversation
There was a problem hiding this comment.
Quote from the issue #1482
Given a numeric literal like -1, this becomes an AST like unary_minus(literal(1)) which has strange downstream implications. The desired behavior is to have the sign as part of the literal like literal(-1).
Could you please elaborate why you think unary_minus(literal(1)) is a bad idea?
I don't know if this is worth to attempt to lower some nodes during the parsing stage.
I see that you listed pretty printer as an example, but I feel like outputting -(1) is fine and if we want to change this, it might be better to modify the pretty printer instead of the parsing logic.
| // If argument is not a literal, then return the op. | ||
| val arg = visit(ctx.rhs) as Expr | ||
| return when (arg) { | ||
| is Expr.Lit -> arg.negate(op) |
There was a problem hiding this comment.
I think this potentially can cause overflow:
-(-2147483648) => 2147483648 which can not be represented by 32 bit integer.
Conformance comparison report
Number passing in both: 5423 Number failing in both: 431 Number passing in Base (ac23bbc) but now fail: 0 Number failing in Base (ac23bbc) but now pass: 0 |
Relevant Issues
#1482
Description
Applies +/- signs to numeric literals.
Other Information
Updated Unreleased Section in CHANGELOG: [YES/NO]
No
Any backward-incompatible changes? [YES/NO]
No
Any new external dependencies? [YES/NO]
No
Do your changes comply with the Contributing Guidelines
and Code Style Guidelines? [YES/NO]
Yes
License Information
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.