Significant but hard-to-find bug in parsing arrow functions

[Lucretiel]

As of a recent release (Don't know when, exactly, but this issue broke code that was working fine around June 4), babylon's parsing of arrow functions has broken in a very peculiar way. When babylon encounters the following pattern:

<some expression> :
    <a parenthesized arrow expression> ?
    <an unparenthesized arrow expression>

It reports an error parsing the parenthesized arrow expression:

Module build failed: SyntaxError: <path to file>: Assigning to rvalue (23:3)

For example:

let x = foo() ?
    (value => true) :
    value => false

The contents of the condition don't seem to matter, nor does parenthesizing the entire conditional expression. However, if the parenthesis around the first arrow function are removed, or parenthesis are added to the second arrow function, or either arrow function is something other than an arrow function, it is parsed fine. This specific pattern is the only one that triggers the error.

For what it's worth, I'm running babylon via babel via webpack, but the stack trace I get is entirely from babylon.

This seems implausible, I know, so I've created a git repo which reproduces the error, available here:

https://github.com/Lucretiel/babylon-error

The specific file I'm trying to pack is index.js with no dependencies or requires. The raw output from webpack is in build_result.

[Lucretiel]

Quick follow up: I've just discovered that this bug ONLY manifests itself if the react babel preset is being used, so I'll copy-paste this issue over there, too: https://phabricator.babeljs.io/T7463

[hzoo]

Ok, so it only happens when flow/jsx parsing is on

[danez]

I just did a git bisect and this is the result:

d15a231 is the first bad commit

I will have a look what my change broke.

[danez]

After digging around I also found this case which is not working anymore:

a ? (b): c => d

Because babylon with flow now sees the "valid-looking" arrow function (b): c => d.

Thinking about reverting my change and then reopening the other bug and redoing the fix with this in mind.

[babel-bot]

This issue has been moved to babel/babel#6723.