Commit Graph

2 Commits

Author SHA1 Message Date
Alan Pierce fbc77f7445 Properly update location data when setting a call to use `new`
This is an upstream port of https://github.com/decaffeinate/coffeescript/pull/24

In a case like `new A().b(c)`, the jison structure ends up being different from
the resulting AST. To the jison parser, this is the `new` unary operator applied
to the expression `A().b(c)`. When the unary operator is applied, the
`Call.prototype.newInstance` function traverses into the leftmost function call
and sets the `isNew` flag to true, and the `Op` constructor returns the `Call`
node so that the call is used in place of the unary operator. However, the code
wasn't updating the node location data, so this commit fixes that.

It's sort of hard to get the location data in `newInstance`, so we set a flag on
every affected node in `newInstance` and override `updateLocationDataIfMissing`
(which is called with the location data after the fact) so that it updates just
the starting position.
2017-02-16 20:43:19 -08:00
Alan Pierce e14946b3e6 Define proper operator precedence for bitwise/logical operators
This is an upstream port for the patch https://github.com/decaffeinate/coffeescript/pull/8

See https://github.com/decaffeinate/decaffeinate/issues/291 for the bug that this fixed.

For the most part, CoffeeScript and JavaScript have the same precedence rules,
but in some cases, the intermediate AST format didn't represent the actual
evaluation order. For example, in the expression `a or b and c`, the `and` is
evaluated first, but the parser treated the two operators with equal precedence.
This was still correct end-to-end because CoffeeScript simply emitted the result
without parens, but any intermediate tools using the CoffeeScript parser could
become confused.

Here are the JS operator precedence rules:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence

For the most part, CoffeeScript already follows these. `COMPARE` operators
already behave differently due to chained comparisons, so I think we don't need
to worry about following JS precedence for those. So I think the only case where
it was behaving differently in an important way was for the binary/bitwise
operators that are being changed here.

As part of this change, I also introduced a new token tag, `BIN?`, for the
binary form of the `?` operator.
2016-10-09 14:45:25 -07:00