<!-- Thank you for reporting a possible bug in Node.js. Please fill in as much of the template below as you can. Version: output of `node -v` Platform: output of `uname -a` (UNIX), or version and 32 or 64-bit (Windows) Subsystem: if known, please specify the affected core module name If possible, please provide code that demonstrates the problem, keeping it as simple and free of external dependencies as you can. --> * **Version**: v10.15.0, v10.15.1, v11.8.0 * **Platform**: Linux <name redacted> 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 <!-- Please provide more details below this comment. --> ## 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 ] > ```