Erroneous errors for multiline statements that include BigInt literal suffix

[MatteBru]

• Version: v10.15.0, v10.15.1, v11.8.0
• Platform: Linux 4.15.0-43-generic # 46~16.04.1-Ubuntu SMP Fri Dec 7 13:31:08 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
• Subsystem: REPL

Possibly related to the issues discussed in #24231

When attempting to create a multiline statement that includes the BigInt literal suffix syntax (i.e. Number followed by n to denote a BigInt) causes an erroneous SyntaxError: Invalid or unexpected token to be thrown. This behavior appears to occur only when the end of the statement is not on the same line as the BigInt. For example, the following seems to be erroneous behavior:

> let a = [
... 4,
... 'hello',
... 0xffn,
Thrown:
0xffn,
     ^

SyntaxError: Unexpected end of input

Whereas if the statement ends on the same line, it seems to behave as expected:

> [
... 4,
... 'hello',
... 0xffn]
[ 4, 'hello', 255n ]

The same behavior seems to extend to any multiline statements regardless of whether or not the BigNum is the last thing on the line:

With BigNum:

> function fun(){
... let m = 0xffn; return m;
Thrown:
let m = 0xffn; return m;
                       ^

SyntaxError: Unexpected end of input

Without BigNum:

function fun(){
... let m = 0xff; return m;
... }
undefined

BigNum on same line as closing bracket:

> function fun(){
... let m = 0xffn; return m;}
undefined
> fun()
255n

Edit (Not sure if helpful):

BigInt suffix seems to be picked up as an identifier. Given the following input into REPL:

> [
... 0xffn,

<debugger paused on pressing return key>

pp$4.raise() at line 2753 in internal/deps/acorn/dist/acorn.js is receiving pos = 6, message = "Identifier directly after number (2:4)

That in turn seems to be coming from pp$8.readRadixNumber() at line 4981 in internal/deps/acorn/dist/acorn.js

The issue seems to originate at isIdentifierStart() (internal/deps/acorn/dist/acorn.js:71), which does in fact pick up n as the start of an identifier.

isIdentifierStart() is also called by pp$8.readNumber() when using a normal, non-radix-prefixed number, producing the same result.

isIdentifierStart() is bypassed when the statement is terminated on the same line as the BigInt, which explains why this scenario does not trigger the error:

> [
... 0xffn]
[ 255n ]
>

[targos]

The problem is that acorn doesn't support BigInt literals at the moment. The error only happens when the statement is unfinished because we only try to parse the code with acorn if there is an error.

[targos]

@nodejs/repl should we close this as a known limitation (Node.js, through V8, can support newer syntax that acorn doesn't know about)?

[nickkolok]

This problem looks really annoying, so +1 for fixing it (here or somewhere else). Have anybody reported it to acorn? What is acorn`?

[BridgeAR]

I agree with @targos that this is a known limitation and we should not try to fix this on our side. acorn should support BigInt as soon as it officially landed in the spec. As such it's just a matter of time and we should not add special code that we have to remove later on just for this case.

I am going to close this issue for now. If someone disagrees, please leave a note or just reopen the issue.

[BridgeAR]

I am actually about to fix this.