* Node comes with NPM nowadays, so there’s not really a reason to install CoffeeScript the non-NPM way
* The cake documentation tasks should each have build and watch modes following the same form
* Refactor the build tasks to be more foolproof, including the parser unless it’s explicitly excluded
* Abstract out testing built code, to prepare for watching the build task
* Cake task to cut a new release
* cake build:watch, based on https://github.com/GeoffreyBooth/coffeescript-gulp
* Coding style
* Tests shouldn’t write files in a watched folder
* Don’t crash if the REPL test history file is already gone by the time we try to delete it
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.
This is an upstream port of https://github.com/decaffeinate/coffeescript/pull/17
The lexer generates fake tokens for interpolated heregexes, and the ending
tokens were being placed where the start (inclusive) and end (inclusive) index
were one past the end of the heregex. This meant that in a case like
`[a ///#{b}///]`, the end tokens of the heregex and also the implicit function
call end were all being placed at the `]`, so the AST location data would say
that the function call ends at the end of the `]`.
To fix, I can just subtract 1 from the position of those ending heregex tokens
so that their end lines up with the end of the heregex itself. This is similar
to previous fixes that changed `OUTDENT` and `CALL_END` tokens so that the end
of the token lines up with the end of the AST node.
* Update classes docs for CS2
* Port breaking changes from https://github.com/jashkenas/coffeescript/wiki/%5BWIP%5D-Breaking-changes-in-CoffeeScript-2 into new docs section
* Update browser compiler
* Update re @connec’s notes; split classes section into two sections for classes and working with prototypes; make breaking changes examples editable whenever possible
* Compile all super calls to ES2015 super
This breaks using `super` in non-methods, meaning several tests are
failing. Self-compilation still works.
* Use bound functions for IIFEs containing `super`
`super` can only be called directly in a method, or in an arrow
function.
* Fix handling of `class @A extends A`
This behaviour worked 'for free' when the parent reference was being
cached by the executable class body wrapper. There now needs to be
special handling in place to check if the parent name matches the class
name, and if so to cache the parent reference.
* Fix tests broken by compiling ES2015 `super`
* Disallow bare super
This removes syntax support for 'bare' super calls, e.g.:
class B extends A
constructor: -> super
`super` must now always be followed with arguments like a regular
function call. This also removes the capability of implicitly forwarding
arguments. The above can be equivalently be written as:
class B extends A
constructor: -> super arguments...
* Support super with accessors
`super` with following accessor(s) is now compiled to ES2015
equivalents. In particular, expressions such as `super.name`,
`super[name]`, and also `super.name.prop` are all now valid, and can be
used as expected as calls (i.e. `super.name()`) or in expressions (i.e.
`if super.name? ...`).
`super` without accessors is compiled to a constructor super call in a
constructor, and otherwise, as before, to a super call to the method of
the same name, i.e.
speak: -> super()
...is equivalent to
speak: -> super.speak()
A neat side-effect of the changes is that existential calls now work
properly with super, meaning `super?()` will only call if the super
property exists (and is a function). This is not valid for super in
constructors.
* Prevent calling `super` methods with `new`
This fixes a bug in the previous super handling whereby using the `new`
operator with a `super` call would silently drop the `new`. This is now
an explicit compiler error, as it is invalid JS at runtime.
* Clean up some old super handling code
This was mostly code for tracking the source classes and variables for
methods, which were needed to build the old lookups on `__super__`.
* Add TODO to improve bare super parse error
* Add some TODOs to improve some of the class tests
* Add failing test per #4406
* If a parameter is a function call, define it in an expression within the function body
* Remove the space between `function` and `*` for generator functions, to follow usual ES idiom
* We can collapse `isCall` into `isComplex`
* Don’t need existence check here
* Correct destructured parameter default evaluation order with an incrementing variable (or more generally any complicated parameter that isComplex)
* Try to pull complex parameters out of the parameter list if their order of execution matters; but don’t pull _all_ complex parameters out of the parameter list, so that we don’t lose parameter default values
* Add lots of comments about node special properties
* Err on the side of caution in deciding whether a complex parameter is allowable in a function parameter list rather than the function body (there are lots more detections we could add to find additional “safe” parameters)
* Follow the ES and CS2 convention of assigning parameter default values only when undefined, not when null or undefined
* Along with arrays and empty objects, also let values whose bases are not complex be allowed in the function parameter list (like `obj.prop`)
* Better way to check for undefined parameters when declaring them in a function body
* Once we’ve put a complex parameter in the function body, all following complex parameters go into the function body; no need to create lots of exceptions of when to choose whether to put a complex param in the body
* Rename `isComplex` to `shouldCache` for clarity
Exports that referenced variables assigned in the module would prevent
the referenced variables from being declared, resulting in
ReferenceErrors at run time.
Fixes#4394.
