* Fix transform-arrow-functions in { spec: true } shadowing
The function name matching the variable declaration name could
shadow the actual function object inside the generated function,
leading to invalid behavior due to holding a reference to the
original unbound function.
* Combine it with transform-function-name just to be sure in spec: false
* Revert "Fix transform-arrow-functions in { spec: true } shadowing"
This reverts commit 1cafe2561d0b0ddd181b956a85eb074621da12e8.
* Much simpler version of the above fix
* Missing fixture updates
* Avoid using rest/spread to make the tests pass on node 4
* ...actually update _all_ the fixtures
* 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).
This prevents a requeued path from inheriting a totally wrong scope later on. I can't find exactly where this is happening, but either way a path should only inherit scope from it's ancestors.
* Path#ensureBlock keeps path context
This ensures that if you're inside an ArrowFunction with an expression body (say, you're on the BooleanLiteral in `() => true`), you don't suddenly lose your path context after inserting a variable.
This is because of 82d8aded8e (diff-9e0668ad44535be897b934e7077ecea5R14). Basically, an innocent `Scope#push` caused my visitor to suddenly stop working. Now, we mutate the Path so it's still in the tree.
* Tests
* Return inserted/replaced paths
This gives `Path`’s replacement and insertion methods a consistent
return value: the inserted/replaced paths.
Before, they could return `undefined`, a `node`, or a the current path
inside an array. It was kinda pointless. But now they always return an
array of paths, which is useful for solving
https://github.com/babel/babel/pull/4935#discussion_r96151368.
* Return inserted nodes and not BlockStatement
Addded test for bug #4363
* Cleanups
- `#replaceWith` will now return the current path if it's the same node
- `#insertAfter` and `#insertBefore` use public Path APIs now
- Makes container insertion faster (single splice call)
- Use public APIs in container insertion
- Replacing a statement with an expression returns the expression's path
- Replacing an expression with multiple statements returns the inserted
closure's body's paths.
* Redeclaring a variable counts as a modification.
Fixes#6217.
* Remove "existing" logic from Binding.
Was added in #5745, but no longer triggered since 6536e605a.
* Fix bad Scope#parent caching
Now, we traverse the path until we find a parent scope.
Fixes#6057.
* Fix bad merge
* Remove cached data
* I need to stop using Github editor
* Fix infinite loops due to scopable paths being moved up
This reverts the former fix done in #5743 and always requeues
BlockStatements when they get created.
This also fixes a bug in babel-generator which would indent code
even though no comments are present.
* Changed updateExpression to report itself as violation instead of its argument
* Update getBindingIdentifiers to work with forXStatement and return proper node as violation
* Updated unaryExpression violation to be consistent with changes.
So, I was reading the new Flow type strictness and noticed
https://flow.org/blog/2017/05/07/Strict-Function-Call-Arity/
Specifically, I wondered whether the `sum_all` example would copy the
arguments into an array, then loop over. Sadly, it does.
```js
function sum_all(...rest) {
let ret = 0;
for (let i = 0; i < rest.length; i++) { ret += rest[i]; }
return ret;
}
// output
function sum_all() {
var ret = 0;
for (var _len = arguments.length, rest = Array(_len), _key = 0; _key < _len; _key++) {
rest[_key] = arguments[_key];
}
for (var i = 0; i < rest.length; i++) { ret += rest[i]; }
return ret;
}
```
But then I noticed if I changed `let i = 0` to `let i: number = 0`, it
worked directly on `arguments`. That lead me down a rabbit hole to
`Path#_guessExecutionStatusRelativeTo`. When tracing through, the last
comparison made no sense to me. It was trying to find the index of
`"init"` in a list of `["declarations"]` and `"body"` in `["directives",
"body"]`. Red flags and such.
But it makes sense when you're trying to compare the visitor order of
the common ancestor path. Then we're trying to find `"init"` in a list
of `["init", "test", "update", "body"]`. Oh, and there's `"body"` in
there too! And now we know the `ForStatement`'s `init` is executed
before the `body`.
* Use first binding for multiple var declarations
Since var declarations after initial binding have no effect, use the
first declaration. Fixes#2378
* Include hoisted function bindings
* Missing newline in expected.js
* Simplify constantViolations in new Binding on existing
* clarify comment language
* Additional testcase and require->import refactorings
* Removed duplicated getStatementParent function. Refactored all babel-traverse tests to use ESmodules
