Description
- 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 ]
>