This makes declare class extends behave the same way as in flow
The ast-token after the extends keyword, might be either Identifier or
QualifiedTypeIdentifier
To do that this commits splits the parseGenericType into two functions,
one for parsing genericType and on for qualifiedTypeIdentifier
Flow's "toAssignable" override wasn't calling the inner function,
resulting in the destructuring in an AssignmentPattern not having the
node type changed from ObjectExpression to ObjectPattern, resulting in
"Binding rvalue" thrown from "checkLVal()"
This commit e6c11a0 (#19) made a big performance regression.
The reason was that parseConditional was always cloning the current state
even if no question mark (potential conditional or flow-optional
token) was at the current position.
Simply checking if questionmark matches the current token solves the problem.
Fixes#62
The primary goal of this commit is to add the ability to parse type parameter
declarations with defaults, like `type Foo<T = string> = T`. While I was in the
code, I fixed a few small things, like
* Type parameter declarations need 1 or more type parameters.
* The existential type `*` is not a valid type parameter.
* The existential type `*` is a primary type
* The param list for type parameter declarations now consists of
`TypeParameter` nodes
The fix includes creating a new method on the parser called `parseArrow`.
This new function by default only checks if current position matches an
arrow. If it does returns the `node` otherwise `undefined`.
The flow plugin can then extend this function and correctly parse the typeAnnotation
and add it to the node.
With this change, in the flow plugin there is no need anymore to extend
`parseParenAndDistinguishExpression` and the arrow handling in `parseParenItem`
could also be removed, because it is all handled now in `parseArrow`.
Some existing tests were failing, because `extra->parentesized` is now missing,
but this is correct as it is now inline with parsing without flow annotation. No extra
is added for arrow function without type annotations.
In the expression-parser `this.next()` was replaced by a more specific
`this.expect(tt.parenL)`.
This syntax allows you to specify whether a type variable can appear in
a covariant or contravariant position, and is super useful for, say,
Promise.
Right now this is hacked in jankily, but in the next major release we
should stop using Identifier nodes for type parameters.
An interface export is just like a type export. In fact, it's a syntax affordance which makes the following equivalent:
```javascript
interface I_ { ... }
export type I = I_;
```
```javascript
export interface I { ... }
```
See facebook/flow#1145
This has been a feature in Flow for a long time (couldn't easily find a
specific commit adding this). Interfaces are basically undocumented, though, so
it's easy to see how this was missed.
Removed `@flow` annotation from files that don't actually pass Flow check at the moment. These will be added back file by file once the files are properly converted to use Flow.
Closes#3064
I'm extremely stupid and didn't commit as I go. To anyone reading this
I'm extremely sorry. A lot of these changes are very broad and I plan on
releasing Babel 6.0.0 today live on stage at Ember Camp London so I'm
afraid I couldn't wait. If you're ever in London I'll buy you a beer
(or assorted beverage!) to make up for it, also I'll kiss your feet and
give you a back massage, maybe.
