Arrow function conversion breaks if attached expression has a synthetic leading comment

[mprobst]

TypeScript Version: 2.8.3

Search Terms: automatic semicolon insertion

Code

Imagine you have a TypeScript snippet like so:

const foo = () =>
    // Print "bar"
    console.log('bar');

If a transformer wants to modify the // Print "bar" comment, it must synthesize the comment in front of console.log. My understanding is that to do so, you set the text range of the CallExpr (console.log...) to -1/-1 or set NoLeadingComments on it, and then create a synthetic leading comment on the CallExpr using ts.setSyntheticLeadingComments(...).

When you do that and emit to ES5, TypeScript later on inserts a return statement, and sets the text range of the return statement to match the CallExpr's. That's fine so far, but when the synthetic comment still gets emitted between the return and the expression:

var foo = function () {
    return
    // Print "bar"
    console.log('bar');
};

This causes automatic semicolon insertion, breaking the code above.

I believe TS should move synthetic leading comments onto the returnStatement it creates in es2015.ts in transformFunctionBody when inserting the return.

Expected behavior:

var foo = function () {
    // Print "bar"
    return
    console.log('bar');
};

Actual behavior:

var foo = function () {
    return
    // Print "bar"
    console.log('bar');
};

Playground Link: N/A, need a transformer that synthesizes the comment.

[mprobst]

/CC @weswigham who I think worked on the comment support here. I can try my hand at a PR if you think this is the right direction (moving synthetic comments).

[weswigham]

Hm. I also actually just fixed an issue with overeager parenthesis/cast elision here causing ASI problems, too. In addition to moving the comments, another option is parenthesizing the expression, should it have any leading comments.

cc @rbuckton you have any preference, moving comments vs parenthesizing the expression?

[mprobst]

@weswigham yeah, this appears to be a bit fickle. I suggested moving synthetic comments as that matches behavior without synthetic comments (moving the comment in front of the return), but parenthesizing might indeed be more robust.

[rbuckton]

Moving the comment seems like the right thing to do in this situation.

[mhegazy]

looks like a duplicate of #24021

[rbuckton]

Not exactly. That issue is more to do with source comments and preserving the parens. This issue is with synthetic comments added via a transform.