Open kddnewton opened 5 months ago
You must note that this is particular to integer constants.
+5
is interpreted by Ruby as a literal corresponding to5
, but foo = 5; +foo
will behave how you expected it to.
OTOH, there does indeed seem to be a bug in the result from parser
, in the case of +5
I think there shouldn't be a send :@+
at all.
Note that this is only the case with integer literals:
$ ruby-parse -e "foo = 5; +foo ** 2"
(begin
(lvasgn :foo
(int 5))
(send
(send
(lvar :foo) :+@) :**
(int 2)))
I believe this will be a problem with any number constants, not just integers.
Sorry, I did mean number, you are correct.
Thanks for reporting. Does this bug (or #1017) impact Prism's test suite? If not I'll fix it "later", nobody else seems to need it.
Thanks @iliabylich no rush at all, I'm just excluding those tests from the test suite that compares the AST translation. So it's no rush.
There are two issues with unary
+
precedence that I can find.The first is that the parser is creating a
send
node, when there isn't really going to be a method call. This is, for example:As you can see, the space affects the result. If there is no space, then no method call is generated. However, in both cases you get the same AST:
The other issue is that the precedence in this AST is incorrect in both cases. This is implying that the expression should be parsed as:
but in reality, in both cases it should be parsed as: