[P2] Compiler: generic class-expression lexical super leaves constructor this unbound

Open
  • Is something wrong?
#3,484 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
30/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp, typescript
Domain
backend, compilers

Research direction

Start with the reported failure through $ClassDefinition.InitializeReceiver and the generic-owner guard; compare the behavior with the retained evidence in artifacts/p3-compiler/lexical-generic-boundary.ts, .log, .dll, and check-lexical-boundary-oracles.cjs. Reproduce the saved-IL execution failure and trace how lexical super() binds constructor this for generic class expressions. Done means the stated acceptance cases pass while complete saved-IL verification and native admission behavior are preserved.

Written by the indexing model from the issue text.

Description

bug priority: P2

Generic class-expression constructors still leave this unbound when super() runs through a lexical arrow.

const C = class<T> extends class { constructor() {} } {
    value: T;
    constructor(value: T) {
        const initialize = () => super();
        initialize();
        this.value = value;
    }
};
console.log(new C<number>(7).value);

TypeScript 6.0.3 ES2022 transpilation executed by Node prints 7. SharpTS accepts this TypeScript source, saves the assembly, and passes complete IL verification, but executing it throws guest ReferenceError: Must call super constructor before accessing this through $ClassDefinition.InitializeReceiver.

Verified with the CLI built from the open P3 batch after the managed nongeneric element transport work for #3477. Evidence is retained in artifacts/p3-compiler/lexical-generic-boundary.ts, .log, .dll, and check-lexical-boundary-oracles.cjs. No introducing-commit claim is made.

This is distinct from #3477's nongeneric user-class field/accessor/private-brand and constructor-parameter transport. The existing generic-owner guard was deliberately retained: invoking a helper on an open generic CLR owner from a nongeneric arrow needs an explicit canonical closed-owner binding, not removal of the guard or reliance on raw reflection lookup.

Acceptance: generic class-expression lexical super binds the same constructor this cell, initializes own elements once, preserves current constructor parameter bindings and new.target, and retains complete saved-IL verification. Cover different closed instantiations and inherited generic owners without broadening native admission.

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.