[P2] Compiler: lexical super in Array subclass emits uninitialized constructor IL

Open
  • Is something wrong?
#3,485 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
compilers

Research direction

Start with the retained fixture at artifacts/p3-compiler/lexical-array-boundary.js and the oracle script check-lexical-boundary-oracles.cjs, then trace how lexical super() is lowered for intrinsic Array subclasses with instance fields. Reproduce the compile using the command in the issue and inspect the saved IL verification errors in lexical-array-boundary-js.log. Done means the fixture passes complete saved-IL verification, constructs and initializes the Array subclass as described, and preserves the stated repeated-super behavior and native refusal boundaries.

Written by the indexing model from the issue text.

Description

bug priority: P2

A lexical super() arrow in an intrinsic Array subclass emits invalid constructor IL when the subclass has an instance field.

const C = class extends Array {
    value = 7;
    constructor() {
        const initialize = () => super();
        initialize();
    }
};
const value = new C();
console.log(value.value, Array.isArray(value));

Node, including the TypeScript 6.0.3 ES2022 transpilation oracle, prints 7 true. Compile this as .js without --checkJs:

dotnet SharpTS.dll --compile lexical-array-boundary.js -o lexical-array-boundary.dll --verify

SharpTS saves the assembly and then correctly rejects it because full IL verification finds three UninitStack errors in $ClassExpr_1..ctor at offsets 14, 44, and 62. Execution was not attempted after verification failed. Evidence is retained in artifacts/p3-compiler/lexical-array-boundary.js, lexical-array-boundary-js.log, and check-lexical-boundary-oracles.cjs.

Found while verifying #3477's managed user-class element transport. Intrinsic-base construction retains its existing separate lowering and admission rules; it must preserve the intrinsic object's internal slots and cannot be routed through an ordinary user-class initialization adapter simply to pass this fixture. No introducing-commit claim is made.

Acceptance: lexical super in an Array subclass constructs a real Array once, initializes child fields before the arrow resumes, respects repeated-super side effects and rejection, and passes complete saved-IL verification. Preserve existing native refusal boundaries.

Dominant language
C#
Stars
156
Forks
4
Avg merge
15h 1m
Merged PRs (30d)
42

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nickna/SharpTS

All issues in nickna/SharpTS

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.