* Use parseFunctionParams to parse method parameters
* [funct] Set this.state.inGenerator before parsing the function name/params
This allows "yield" inside generator parameters to be actually
parsed as a yield expression
* [funct] Disallow yield in function parameters
* [arrow] "yield" can start an arrow function (e.g. "yield => {}")
* [arrow] Disallow YieldExpressions inside arrow parameters.
* [err msg] Disallow yield as fn name in strict mode using checkReservedWord.
So Babylon throws "yield is a reserved word" instead of
a custom "Binding yield in strict mode"
* [err msg] "X is reserved in strict mode" should have precedence over "X is reserved", since it is more specific.
This was observable if "checkKeywords" is true and the word is both a keyword and a reserved
word in strict mode
* Disallow "yield" as an identifier inside generators
* [tests] Add tests, update wrong esprima tests and enable disabled esprima tests
* [tests] Move uncategorized tests to es2015/yield
* [tests] Update test262 whitelist
* Fix regression introduced by 8c77073
* [tests] Update flow whitelist
* Fix flow errors
- adds `get` and `set` kind in addition to `method` to the list of allowed class members for having a decorator,
- adds tests for this two cases (decorator + set and decorator + get)
* Fix OOB string character access in Printer#_maybeAddParen.
The `_maybeAddParen` method of the `Printer` class does
```js
const chaPost = str[i + 1]
```
without checking that `i + 1` is still within the bounds of `str`. It
seems like this triggers fairly often that the `str[i + 1]` access is
out of bounds. The first out of bounds access will turn the KeyedLoadIC
(in case of V8) into *MEGAMORPHIC* state, which is significantly slower
for strings (there's a fix in flight for V8 to mitigate the cost a bit
in that case). Even worse than that, the out of bounds access also
pollutes the later comparisons, namely
```js
chaPost === "/"
```
and
```js
chaPost === "*"
```
which are now no longer monomorphic on strings, since `chaPost` was
sometimes `undefined`.
This is a non-breaking performance fix, which improves babel execution
on the [web-tooling-benchmark](github.com/v8/web-tooling-benchmark)
workload by around 6-9%.
* Restructure and optimize the code a bit.
* Added tests for ifThrowNamespace flag
* JSX transformator could work with XMLNamespaces (ifThrowNamespace flag)
* Use template literal instead
* Attempt to reword the message
* Added docs
* Reworded docs
* Reworded docs
* Fixed missing space in error message
The code
```js
linesInfo && linesInfo[type]
```
performs a lot of dynamic lookups on the `Boolean.prototype`, as the
*ToBoolean* operation let's `true` pass for `linesInfo` (which might
itself be concerning that this can be a boolean). Instead of the
coercion, the code should properly check for valid objects via `typeof`
and strict equality with `null` comparison.
This is a non-breaking performance fix.
Similar to the fixes in https://github.com/babel/babel/pull/6580 and
https://github.com/babel/babel/pull/6581, accesses of the form
```js
nodesOut[nodesOut.length - 1]
```
where `nodesOut` can be an empty array, are bad for performance in Node.
In this particular case it's easy to restructure the code a bit to not
require the array access at all, but just track the current `tail` as we
go.
This is a non-breaking performance fix.
* Fix path.popContext() to not try to load "-1" from contexts array.
The current implement of popContext does
```js
this.setContext(this.contexts[this.contexts.length - 1]);
```
even if `this.contexts` can be empty, which causes it to lookup the
property `"-1"`, which is not found on the array itself and obviously
also not in the `Object.prototype` and the `Array.prototype`. However
since `"-1"` is not a valid array index, but has a valid integer
representation, this is a very expensive lookup in V8 (and probably
other engines too, but that is probably less relevant, since Babel
most often runs on Node nowadays).
* Make zero check explicit (for readability).
Similar in spirit to https://github.com/babel/babel/pull/6580, the
current implementation did
```js
node.params[node.params.length - 1]
```
where `node.params` can also be empty, which causes it to lookup the
property `"-1"`, which is not found on the array itself and obviously
also not in the `Object.prototype` and the `Array.prototype`. However
since `"-1"` is not a valid array index, but has a valid integer
representation, this is a very expensive lookup in V8 (and probably
other engines too, but that is probably less relevant, since Babel
most often runs on Node nowadays). In V8 this causes a call to
the `%SetProperty` runtime function for each of these `"-1"`
property lookups, and in addition sends the whole `KeyedLoadIC`
to `MEGAMORPHIC` state, which also penalizes other accesses
on this line.
This is a small non-breaking performance fix.
Similar to the fixes in https://github.com/babel/babel/pull/6580 and
https://github.com/babel/babel/pull/6581, accesses of the form
```js
stack[stack.length - 1];
```
when `stack` can be an empty array are pretty bad for performance.
In this case it also breaks the type safety, since the function
`last<T>` is declared to only return values of type `T`, but
occasionally also returns `undefined` now, since the `stack` parameters
passed to it never contain a property `"-1"` and neither do the
`Object.prototype` or the `Array.prototype`.
This is a non-breaking performance fix, which adds proper checking
to ensure that `last` is only invoked on non-empty arrays.
