Missing syntax error for new A?.b()

[nicolo-ribaudo]

Bug Report

🔎 Search Terms

syntax error optional chain new arguments parentheses

🕗 Version & Regression Information

Only tested with 4.7 Nightly in the playground

⏯ Playground Link

Playground link with relevant code

💻 Code

class A {
    b() {}
}

new A?.b()

Output

"use strict";
var _a;
class A {
    b() { }
}
(_a = new A) === null || _a === void 0 ? void 0 : _a.b();

Compiler Options

{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "alwaysStrict": true,
    "esModuleInterop": true,
    "declaration": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "target": "ES2017",
    "jsx": "react",
    "module": "ESNext",
    "moduleResolution": "node"
  }
}

Playground Link: Provided

🙁 Actual behavior

new A?.b() is parsed as if it was new A()?.b()

🙂 Expected behavior

It should be a syntax error, because it's not valid JavaScript syntax.

[fatcerberus]

new A()?.b() is still invalid JS (not true, see comments below). What's interesting is that when targeting esnext, the code is emitted as-is (and is a runtime error), but downlevel emit is doing the equivalent of (new A)?.b() instead.

[nicolo-ribaudo]

new A()?.b() is valid JS (or at least, it's valid in Node.js and Firefox).

[fatcerberus]

Ah, you're right, I thought I had tried it and gotten an "invalid optional chain" error. But yeah, really weird because the esnext emit preserves the runtime SyntaxError while the downlevel emit changes the meaning of the code.