Add ParserOptions.AllowDirectSuperOutsideMethod

[lahma]

Draft — opening for review before it is proposed for merge.

Motivation

ECMA-262's PerformEval passes inDerivedConstructor into the parse of the eval code, so a direct eval called from the constructor of a derived class may legally contain a super call:

class B { }
class D extends B { constructor() { eval("super()") } }

There is currently no way to ask the parser for that. AllowSuperOutsideMethod enables super property accesses only, and AllowDirectSuper is derived from the scope flags alone with no option behind it — unlike its siblings AllowSuper and AllowNewDotTarget. So an embedder that computes inDerivedConstructor correctly still cannot pass it on, and every eval containing a super call comes back as a SyntaxError.

This came up in Jint, which uses Acornima as its front end and already tracks inDerivedConstructor correctly where it parses eval code — the missing piece is purely the parser option. Three test262 conformance tests fail on this today (staging/sm/class/derivedConstructorArrowEvalSuperCall.js, derivedConstructorArrowEvalNestedSuperCall.js, staging/sm/fields/bug1587574.js).

What this adds

ParserOptions.AllowDirectSuperOutsideMethod (default false), declared next to AllowSuperOutsideMethod and following the same pattern — backing field, get/init, copy-constructor entry.

Design: seeding the root scope, not short-circuiting the getter

The obvious implementation — AllowDirectSuper => _options._allowDirectSuperOutsideMethod || … — would be wrong. It would allow

function f() { super() }

at the top level of the parsed unit, which the spec does not: eval code in a derived constructor gets the constructor's this binding, and an ordinary function introduces one of its own.

Instead the option seeds the root scope with the flag pair ParseMethod already uses for a derived constructor:

EnterScope(ScopeFlags.Top | (_options._allowDirectSuperOutsideMethod ? ScopeFlags.Super | ScopeFlags.DirectSuper : ScopeFlags.None));

Because EnterScope propagates the current this scope through arrow function scopes but not through ordinary function scopes, the spec semantics fall out of the existing machinery with no new logic:

code	option on	option off
super()	parses	SyntaxError
(() => super())()	parses	SyntaxError
() => () => super()	parses	SyntaxError
function f() { super() }	SyntaxError	SyntaxError
(function () { super() })	SyntaxError	SyntaxError
({ m() { super() } })	SyntaxError	SyntaxError
class A extends B { m() { super() } }	SyntaxError	SyntaxError

ScopeFlags.Super is seeded alongside DirectSuper for two reasons: AllowSuper is checked first in ParseExprAtom, so DirectSuper alone would leave super() rejected; and a derived constructor is a method, so super property accesses are legal there anyway — which is exactly why ParseMethod sets the same pair.

AllowSuperOutsideMethod and AllowNewTargetOutsideFunction are deliberately untouched: with the new option disabled nothing changes at all.

Tests

ShouldHandleDirectSuperOutsideMethod (37 cases, next to ShouldHandleSuperKeywordEdgeCases and in its style) covers both options in all four combinations across script/module/expression: the top-level and arrow cases, the ordinary-function and method cases that must keep failing, super.x under each option, and class bodies. AllowDirectSuperOutsideMethodShouldDefaultToFalse pins the default and that a with-expression copy keeps the flag.

Green: Acornima.Tests on net462/net8.0/net9.0/net10.0 (13,025–13,028 each), Acornima.Tests.Test262 (99,090), Acornima.Tests.SourceGenerators, solution build with 0 warnings.

Two things noticed while doing this, not fixed here

1. _allowTopLevelUsing is missing from the ParserOptions copy constructor — it is the only bool option that is, so (ParserOptions.Default with { AllowTopLevelUsing = true }) with { EcmaVersion = … } silently drops the flag. Happy to send that as its own one-line PR.
2. A class body enters a non-var scope, so a field initializer does not introduce a this binding. That is why class A extends B { constructor() { class C { x = super() } } } already parses on master (V8 rejects it), and consequently class C { x = super() } parses when this option is on. Same quirk, inherited from acorn — both rows are pinned in the new theory with a comment rather than changed.

[adams85]

Even though this is still a draft, let me add my initial thoughts:

First of all, I see this feature is needed for Jint to fully support eval, so I have no objections.

At first glance, the implementation looks good too. However, once we touch this area, I'd prefer to align the behavior of the existing AllowSuperOutsideMethod with this new option.

I mean that currently function f() { super.m() } is incorrectly accepted with AllowSuperOutsideMethod = true, while function f() { super() } will be rejected with AllowDirectSuperOutsideMethod = true. I think the latter approach is the correct one, regardless of what the upstream project does.

So, could you update Parser.AllowSuper to work similarly to AllowDirectSuper?

But before doing anything, please rebase this PR onto master so we can see whether it passes the tests I added for some edge cases here.

FWIW, this commit of mine also fixes a parser bug:

class C extends Object {
  constructor() {
    class X { p = super() }
  }
}

This edge case was incorrectly accepted since v1.1.1.

BTW, this will be an interesting edge case for Jint too:

new (class extends Object {
  constructor() {
    class X { static p = eval('super()') }
  }
})

And also:

new (class extends Object {
  constructor() {
    class X { static [eval('super()')]() { } }
  }
})

This evil eval one is syntactically and semantically valid! 🤯

[lahma]

Rebased onto master (so it now sits on top of 33a8c34) and addressed the review.

The rebase changed two expectations, and 33a8c34 is why. With ParseClassField clearing DirectSuper from the this scope, a direct super call in a field initializer is now rejected wherever the field lives, so these two rows flipped to an error and the comment that predicted the opposite is gone:

class A extends B { constructor() { class C { x = super() } } }   // was accepted, now rejected
class C { x = super() }                                           // with the option on: was accepted, now rejected

Both flips are right: §15.7.1 makes it a Syntax Error if a FieldDefinition's Initializer Contains SuperCall, unconditionally, so no context and no option should ever admit one there. Added class C { [super()]() { } } alongside them to pin the other half — a computed class element name is evaluated in the enclosing scope, so it does follow the option.

AllowSuperOutsideMethod now works the way you asked. Instead of short-circuiting the AllowSuper getter, the option seeds the root scope with ScopeFlags.Super in Reset, exactly as the new one seeds Super | DirectSuper. Both therefore follow the top level's this binding: allowed at the top level and in arrow functions declared there, not in ordinary functions. So function f() { super.m() } is no longer accepted with the option on, which is the behaviour you preferred, and the two options are now the same shape rather than two different mechanisms.

AllowDirectSuperOutsideMethod implies AllowSuperOutsideMethod; that is stated in the XML docs, and AllowSuperOutsideMethod's own docs got the inMethod half of the PerformEval story to match.

Suites at head 08c6a63: Acornima.Tests 13093 / 13090 / 13090 / 13090 across net10.0 / net9.0 / net8.0 / net462, all green; Acornima.Tests.Test262 99090 / 99090.

Verified downstream as well, which is what this option exists for. A local Acornima built from master + this PR + #48 + #49, consumed by Jint with the option wired into PerformEval from its already-computed inDerivedConstructor, takes Jint's test262 run from 102,495 passed / 189 skipped to 102,505 passed / 179 skipped, 0 failed — the three super()-in-eval files that were excluded now pass, and nothing else moved. The scoping is what makes the wiring honest: Jint can turn the option on for the eval and still have the parser refuse eval("(function () { super() })"), which the specification refuses too.

[adams85]

I'd suggest naming the new option AllowSuperCallOutsideConstructor for maximum clarity. (As a matter of fact, AllowSuperAccessOutsideMethod would be a better name for the existing one, but I'd rather not introduce a breaking change.)

Does this work for you?

[lahma]

Yes, AllowSuperCallOutsideConstructor is the better name — it says which construct it admits (a super call) and where the option pretends the code sits (outside a constructor), which is exactly the inDerivedConstructor half of PerformEval. And I agree about the existing one: AllowSuperAccessOutsideMethod would read better, but not worth a breaking change for.

Your f1b91b6 had already done the rename in the public API, so I only carried it through to the places it hadn't reached — the test method names (ShouldHandleSuperCallOutsideConstructor, AllowSuperCallOutsideConstructorShouldDefaultToFalse), the theory parameter, and one comment that still said AllowDirectSuperOutsideMethod. Pushed as b468b89; no behavior change, so the AllowDirectSuper scope-flag getter keeps its acorn name.

Suites at that head, all green: Acornima.Tests 13093 / 13090 / 13090 / 13090 on net10.0 / net9.0 / net8.0 / net462, Acornima.Tests.Test262 99090.

The PR title and the opening description still use the old name; I'll leave them as they are unless you'd like them rewritten, since the discussion above is easier to follow with the original wording intact.