{"push_id":1376263687,"size":2,"distinct_size":1,"ref":"refs/heads/decaffeinate-fork-1.10.0","head":"c103efc0cd9b18e529265c6eb7cabf1986de3c45","before":"85f3fc005fdb31b655af2ee658480990b1bacb9a","commits":[{"sha":"f9a8f543256b4cc90dc4d2d1960fbd3d1e308587","author":{"name":"Alan Pierce","email":"d34ec7139604a3b9d8ba8ff59e142f00e8205dd9@gmail.com"},"message":"fix: define proper operator precedence for bitwise/logical operators (#8)\n\nCloses https://github.com/decaffeinate/decaffeinate/issues/291\r\n\r\nFor the most part, CoffeeScript and JavaScript have the same precedence rules,\r\nbut in some cases, the intermediate AST format didn't represent the actual\r\nevaluation order. For example, in the expression `a or b and c`, the `and` is\r\nevaluated first, but the parser treated the two operators with equal precedence.\r\nThis was still correct end-to-end because CoffeeScript simply emitted the result\r\nwithout parens, but any intermediate tools using the CoffeeScript parser could\r\nbecome confused.\r\n\r\nHere are the JS operator precedence rules:\r\nhttps://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence\r\n\r\nFor the most part, CoffeeScript already follows these. `COMPARE` operators\r\nalready behave differently due to chained comparisons, so I think we don't need\r\nto worry about following JS precedence for those. So I think the only case where\r\nit was behaving differently in an important way was for the binary/bitwise\r\noperators that are being changed here.\r\n\r\nAs part of this change, I also introduced a new token tag, `BIN?`, for the\r\nbinary form of the `?` operator.","distinct":false,"url":"https://api.github.com/repos/alangpierce/coffeescript/commits/f9a8f543256b4cc90dc4d2d1960fbd3d1e308587"},{"sha":"c103efc0cd9b18e529265c6eb7cabf1986de3c45","author":{"name":"Alan Pierce","email":"d34ec7139604a3b9d8ba8ff59e142f00e8205dd9@gmail.com"},"message":"fix: properly set location for string tokens ending in a newline (#9)\n\nFixes https://github.com/decaffeinate/decaffeinate/issues/457\r\n\r\nThe existing logic for computing the end location of a string was to take the\r\nend of the string contents, then add the delimiter length to last_column. For\r\nexample, `\"\"\"abc\"\"\"` would have an end position three characters after the `c`.\r\nHowever, if a string ended in a newline, then the end location for the string\r\ncontents would be one line above the end location for the string, so the proper\r\nfix is to move the end location to the next line, not just to shift it to the\r\nright.\r\n\r\nThis avoids a bug where the location data would sometimes reference a\r\nnon-existent location (one past the end of its line), which would confuse\r\ndecaffeinate-parser.","distinct":true,"url":"https://api.github.com/repos/alangpierce/coffeescript/commits/c103efc0cd9b18e529265c6eb7cabf1986de3c45"}]}
{"actor":{"display_login":"alangpierce"}}