tsc produces invalid JavaScript when there is a comment between a numeric literal and a method call on that number

[T-Hugs]

TypeScript Version: 3.2.1

Search Terms: allowjs comment number numeric literal two dots after comment

Code
file.js

0 /* any comment */.toString();

Run: tsc file.js --allowJS --outFile out.js

Expected behavior:
out.js has the same content as file.js

Actual behavior:
out.js contains the following:

0 /* any comment */..toString();

Which is a syntax error: SyntaxError: Unexpected token .

[a-tarasyuk]

@DanielRosenwasser seems that problem in this condition

https://github.com/Microsoft/TypeScript/blob/24759b81e62b75d02a8adde1cf522c08ac087f2e/src/compiler/emitter.ts#L1667

The method https://github.com/Microsoft/TypeScript/blob/24759b81e62b75d02a8adde1cf522c08ac087f2e/src/compiler/emitter.ts#L1680

does not handle the situation if there is comment between dot and primitive. In plain JavaScript we cannot write 0.toString() however we can write 0 /**/ .toString(); Babel just wraps numerical literal to () - 0 /**/ .toString(); to (0) /**/ .toString();.

Is there any method to check if comment exists between numeric literal and dot?

[DanielRosenwasser]

skipTrivia has an optional parameter to stop at the first comment it hits, so you can run it twice to see if it produces a different result when that option is set. That's what I did in #28888.

[a-tarasyuk]

@DanielRosenwasser ok, I got, thanks. 👍

[fatcerberus]

Is there a reason TypeScript even allows this (and Babel, apparently) when the ES specification does not? I guess it technically doesn’t violate the “TS is a superset” principle but still seems unusual given the general resistance to adding expression-level syntax (other than type info) that’s not in ES.

That said, I actually hadn’t realized you could get around this limitation in JS just by adding another dot—I always just wrapped the literal in ()...

[DanielRosenwasser]

when the ES specification does not?

Huh?

[fatcerberus]

What I mean is that in standard JavaScript, 2.toString() is a syntax error. Apparently in TS it isn’t and the compiler produces code that allows it to work (the second dot)? Unless I misunderstood the issue?

[DanielRosenwasser]

Ah, gotcha. TypeScript does provide an error:

and 3.3+ is going to provide a better error:

But we do a best-effort emit unless a user uses --noEmitOnError since the idea is users often need to be trusted and errors shouldn't block emit (especially in migration scenarios). We used to have a distinction between semantic errors and syntactic errors (the latter would block emit); but for various reasons around efficiency we moved these error checks into a separate phase and this distinction became untenable to keep around.

[fatcerberus]

Thanks, I knew about noEmitOnError (I use it myself even), I didn’t know that it ignores syntax errors though—assumed it was only for ignoring type checker errors (as you say it was originally). I’m learning all sorts of new stuff today!