7 Commits

Author SHA1 Message Date
Andy
0545173f66 Test runner: Detect extra property in 'actual' but not in 'expected'. (#407)
* Test runner: Detect extra property in 'actual' but not in 'expected'.

Also update all expected.json where this would result in errors.

* Include rmExpected.js script in case it is needed again
2017-03-19 22:03:11 +01:00
Daniel Tschinder
e614032504 Change location of ObjectTypeIndexer to match flow (#228) 2017-01-27 23:08:20 +01:00
Sam Goldman
26809e8ce7 Property variance type annotations for Flow plugin (#161)
* 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
2016-10-14 23:13:27 +02:00
Gabe Levi
fe5193a40a Support defaults in Flow's type parameter declarations
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
2016-04-27 16:12:10 -04:00
Sebastian McKenzie
e7fec51feb remove range property from nodes, clean up babylon codebase 2015-07-25 07:07:22 +01:00
Sebastian McKenzie
006f3db76a update babylon fixtures to use File as the root node rather than Program 2015-07-25 05:24:58 +01:00
Sebastian McKenzie
b088f8e6ef switch babylon tests to fixtures 2015-07-25 05:19:32 +01:00