Fix comment emit inside for arrow functions.

[mprobst]

Previously, tsickle would synthesize a comment for expression bodies of
arrow functions:

var x = () =>
    // comment
    1;

This would cause the comment to be emitted in between the return
statement and the expression after TS transform:

var x = function() {
    // comment
    return
    // comment
    1;
}

The first comment is TS correctly transforming the arrow function, the
second comment is tsickle re-emitting the synthesized comment, causing
Automatic Semicolon Insertion and thus breaking the code.

The fix is to just not do that - TypeScript emits comments in the
expression correctly, and tsickle already avoids modifying the comment
exactly because emitting comments in arrow functions is dangerous.

Fixes #802.

[mprobst]

This is a workaround for microsoft/TypeScript#24096.

[rkirov]

Reading the function documentation "prevent the comment text ranges to be emitted, to allow changing these comments.", means that because that trick doesnt work for arrow functions we just reuse the TS mechanism at the cost of not being able to change the comment if we needed to. Is this correct?

[rkirov]

OOC, why is the 'as ts.Node' cast needed. Looking at <T extends ts.Node> and node: T that should be superfluous.

[mprobst]

I don't know, it's odd indeed. Without it, TS complains that .kind can only be [long list of SyntaxKind union type], but never ts.SyntaxKind.Block. It is though, and it can – TS must be incorrectly inferring a partial subtype here.

[mprobst]

Reading the function documentation "prevent the comment text ranges to be emitted, to allow changing these comments.", means that because that trick doesnt work for arrow functions we just reuse the TS mechanism at the cost of not being able to change the comment if we needed to. Is this correct?

Yes, that's correct. We don't emit comments for arrow functions like this anyway, because they don't quite work and can cause issues with semicolon insertion (e.g. when returning an arrow function we'd also introduce an incorrect wrap). So this doesn't regress anything that worked previously, but might be something we should revisit once the issue on the TS side is fixed (TS 2.9.1).