This repository has been archived by the owner. It is now read-only.

Fix support for flow optional parameters in arrow functions #19

Merged
merged 1 commit into from Jun 22, 2016

Conversation

Projects
None yet
3 participants
@danez
Copy link
Member

danez commented Apr 10, 2016

This fixes cases like this:

var f = (x?) => {}

The main issue was that parseMaybeConditional was detecting the question mark as start of a ternary operator, and failed because it obviously is not one.

To fix it parts of parseMaybeConditional was split into parseConditional and then overwritten in the flow plugin. There the main implementation is called, but syntax errors are catched and the state reseted to the question mark. The question mark can then be handled in parseParenItem.
The rest of the changes is to ensure that the optional operator only works in arrow functions.

Fixes T7096

Fix support for flow optional parameters in arrow functions T7096
This overwrites the conditional handling in babylon for flow to support
optional parameters in arrow functions.

@danez danez force-pushed the danez:fix-flow-optional-type branch from bf65ce0 to e6c11a0 Apr 10, 2016

@kittens kittens merged commit e6c11a0 into babel:master Jun 22, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@danez danez deleted the danez:fix-flow-optional-type branch Jun 22, 2016

danez pushed a commit to danez/babylon that referenced this pull request Jul 2, 2016

Daniel Tschinder
Fix performance regression introduced in 6.8.2
This commit e6c11a0 (babel#19) made a big performance regression.
The reason was that parseConditional was always cloning and doing state
reverse even if no questionmark (potential conditional or flow-optional
token) was at the current position.
Simply checking if questionmark matches solves the problem.

Fixes babel#62

danez pushed a commit to danez/babylon that referenced this pull request Jul 2, 2016

Daniel Tschinder
Fix performance regression introduced in 6.8.2
This commit e6c11a0 (babel#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 babel#62

danez pushed a commit to danez/babylon that referenced this pull request Jul 3, 2016

Daniel Tschinder
Fix performance regression introduced in 6.8.2
This commit e6c11a0 (babel#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 babel#62

danez pushed a commit to danez/babylon that referenced this pull request Jul 3, 2016

Daniel Tschinder
Fix performance regression introduced in 6.8.2
This commit e6c11a0 (babel#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 babel#62
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.