[parser] parse arrow function only if no linefeed before =>

[parser] parse arrow function only if no linefeed before =>

BUG=v8:3954
LOG=N
R=arv@chromium.org

Committed: https://crrev.com/f950ddf581a29c6aac421a0f2fb7cbda783c217e
Cr-Commit-Position: refs/heads/master@{#27122}

[caitp (gmail), 2015-03-10 17:22:25]

PTAL --- much tinier fixup for arrow fns this time =)

I'm not totally sure about the `( (a) \n => a )` case, to me it feels like the
surrounding parentheses should prevent ASI. But the spec seems to argue that
that doesn't happen

[arv (Not doing code reviews), 2015-03-10 17:39:55]

LGTM

https://codereview.chromium.org/987203003/diff/1/src/preparser.h
File src/preparser.h (right):

https://codereview.chromium.org/987203003/diff/1/src/preparser.h#newcode1683
src/preparser.h:1683: 
too many new lines

https://codereview.chromium.org/987203003/diff/1/src/preparser.h#newcode1683
src/preparser.h:1683: 
too many new lines

[caitp (gmail), 2015-03-10 17:41:55]

https://codereview.chromium.org/987203003/diff/1/src/preparser.h
File src/preparser.h (right):

https://codereview.chromium.org/987203003/diff/1/src/preparser.h#newcode1683
src/preparser.h:1683: 
On 2015/03/10 17:39:55, arv wrote:
> too many new lines

oops, fixed

[caitp (gmail), 2015-03-10 18:59:31]

The CQ bit was checked by caitpotter88@gmail.com

[caitp (gmail), 2015-03-10 18:59:31]

The patchset sent to the CQ was uploaded after l-g-t-m from arv@chromium.org
Link to the patchset: https://codereview.chromium.org/987203003/#ps20001 (title:
"Remove extra newline between functions")

[commit-bot: I haz the power, 2015-03-10 18:59:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/987203003/20001

[commit-bot: I haz the power, 2015-03-10 19:24:54]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-03-10 19:25:13]

Patchset 2 (id:??) landed as
https://crrev.com/f950ddf581a29c6aac421a0f2fb7cbda783c217e
Cr-Commit-Position: refs/heads/master@{#27122}

[marja, 2015-03-10 19:29:44]

I'm confused! I always thought that the rule is "a semicolon is inserted *only*
if it's a syntax error without the semicolon".

Is this no longer true? What's going on here? Is there an additional restriction
that there cannot be a line feed between params and arrow, independent of ASI?

[caitp (gmail), 2015-03-10 19:36:19]

On 2015/03/10 19:29:44, marja wrote:
> I'm confused! I always thought that the rule is "a semicolon is inserted
*only*
> if it's a syntax error without the semicolon".
> 
> Is this no longer true? What's going on here? Is there an additional
restriction
> that there cannot be a line feed between params and arrow, independent of ASI?

From
`https://people.mozilla.org/~jorendorff/es6-draft.html#sec-grammar-notation`

```
If the phrase “[no LineTerminator here]” appears in the right-hand side of a
production of the syntactic grammar, it indicates that the production is a
restricted production: it may not be used if a LineTerminator occurs in the
input stream at the indicated position. For example, the production:

ThrowStatement :
throw [no LineTerminator here] Expression ;
indicates that the production may not be used if a LineTerminator occurs in the
script between the throw token and the Expression.
```

Since the arrow function production requires that there is no line terminator
before the `=>`, then we need to treat it as though there was a semicolon. `var
fn = (a)\n` would be perfectly valid in ES5, so it's still valid in ES6, but
there's a syntax error if the next statement starts with `=>`.

[arv (Not doing code reviews), 2015-03-10 19:43:24]

On 2015/03/10 19:36:19, caitp wrote:
> On 2015/03/10 19:29:44, marja wrote:
> > I'm confused! I always thought that the rule is "a semicolon is inserted
> *only*
> > if it's a syntax error without the semicolon".
> > 
> > Is this no longer true? What's going on here? Is there an additional
> restriction
> > that there cannot be a line feed between params and arrow, independent of
ASI?
> 
> From
> `https://people.mozilla.org/~jorendorff/es6-draft.html#sec-grammar-notation`
> 
> ```
> If the phrase “[no LineTerminator here]” appears in the right-hand side of a
> production of the syntactic grammar, it indicates that the production is a
> restricted production: it may not be used if a LineTerminator occurs in the
> input stream at the indicated position. For example, the production:
> 
> ThrowStatement :
> throw [no LineTerminator here] Expression ;
> indicates that the production may not be used if a LineTerminator occurs in
the
> script between the throw token and the Expression.
> ```
> 
> Since the arrow function production requires that there is no line terminator
> before the `=>`, then we need to treat it as though there was a semicolon.
`var
> fn = (a)\n` would be perfectly valid in ES5, so it's still valid in ES6, but
> there's a syntax error if the next statement starts with `=>`.

To be fair, the restriction in this case makes no sense since you would get a
syntax error in either case.

IIRC, the [no LineTerminator here] was added for future extensions. We have
talked about allowing `=> {}` (optional params) and then the case `x\n=>{}`
would be ambiguous.