Some function types fail to parse inside arrow functions

[mroch]

Bug Report

Current Behavior
let x = (): (T) => U => 123 is a parse error, to avoid ambiguity/lookahead after the first =>. Wrapping the return type in parens avoids the ambiguity: let x = (): ((T) => U) => 123

But it fails to parse when a function type is nested inside a generic, inside the return type (see below), even though that similarly delimits the nested function type.

Input Code
https://astexplorer.net/#/gist/af5836b64b734d2c74496bbcccec6f3e/305660c62c2d85a3475bf5df4e35fe40a3be29cc

var x = (): Array<(string) => number> => [];

Expected behavior/code
Should parse as a function type with an anonymous string param, inside an Array generic type, inside the return type annotation of an arrow function.

Environment

• Babel version(s): 7.0.0
• How you are using Babel: astexplorer

Possible Solution
See related Flow parser fix: facebook/flow@607e9fa

I'm not sure how it's implemented in Babylon, but I'm guessing the fix might be similar.

[babel-bot]

Hey @mroch! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

[danez]

Just to clarify:
This is NOT a parse error:

let x = (): (string) => number => 123

whereas this is:

let x = (): (string) => 123 => 123

This is both true for latest babel-parser and flow 0.85.

That is correct I guess, because the first is not ambiguous?