* Parse flow nested array type annotations like number[][]
Fixes#217.
* Do not parse a newline separated array statement into a flow type annotation
* Get rid of lineBreak dependency in flow.js in favor of higher level method
* Use .gitattributes to ignore files with weird newlines
* [Flow] Make parameter names in function types optional
* [Flow] Anonymous function types with single params can omit parens
* [Flow] Optional names for object indexer keys
* Add noAnonFunctionType explicitly to state
* Adjust gitattributes as files have been fixed
* Increase test coverage
* Test for error when binding `this` in destructuring pattern
* Ignore coverage of inAsync check in parseAwait - already checked externally
* Ignore coverage of default case in checkPropClash
* Remove unused parameter isAsync from parseParenAndDistinguishExpression
* Ignore coverage of an `else` branch in flowParseTypeParameterDeclaration
* Flow: remove unused parameters to flowParseTypeAnnotatableIdentifier
* Flow: ignore coverage of pass-through throw statement in parseConditional
* Flow: Add test for error on property with type param
* Flow: ignore coverage of pass-through throw statements in parseMaybeAssign, parseArrow
* Add test for error on XML-style comment in module code
* Update test for error on method in object pattern
* Test for error: "Only '=' operator can be used for specifying default value"
* Property variance type annotations for Flow plugin
Non-method properties and indexers of object types, declare class, and
interfaces can be "positive" or "negative." Class fields, but again not
methods, can also have variance.
This PR generalizes the variance annotations for type parameters into a
new node type, and reuses that node for those properties.
The code for object types is reused for interfaces and declare classes.
The changes there are straightfoward.
The code for class fields is reused for object literals, which do not
support variance annotations (currently). This code is a bit sketchy,
because we always parse variance annotations in the `parsePropertyName`
extension, then error in a the subsequent parse phase for object
literals (`parseObjPropValue`) or class methods (`parseClassMethod`).
* Remove bogus unreachable code, clarify variance parsing conditional
* Don't use a new node type for variance annotations
Adding a new node type, specifically changing the TypeParameter node's
variance property to be node-valued, is a breaking change. We might
choose to make this breaking change in a later version.
* s/start/variancePos
I also noticed that there was missing test coverage for builtin types,
so I added a test for that, which includes the newly added type as well
as the other existing types.
* Rephrase "assigning/binding to rvalue" error messages with context (#119)
* Fix code style in parser/lval.js
* istanbul ignore some unused branches in parser/lval.js
* Fix code style again in parser/lval.js
* exact object type annotations for Flow plugin
* Couple tweaks per suggestions
* s/==/===/
* add test for unexpected token in flowObjectType Semicolon
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.
