Repository navigation
JavaScript: aliased constructor receivers and overridden super calls remain unresolved #2497
Description
Two explicit JS patterns lose method-call targets in v1.6.2/source main fc0da38f:
// left.js
export class Left { show() { return 'left'; } }
// consumer.js
import { Left as Known } from './left.js';
export function invoke() {
const item = new Known();
return item.show();
}Expected: invoke calls Left::show. Actual: new Known() finds Left, but item.show() is unresolved. The unaliased import/construction works. A second class with show() must not become the target merely because its name matches.
// base.js
export class Base { run() { return 1; } }
// child.js
import { Base } from './base.js';
export class Child extends Base {
run() { return super.run(); }
}Expected: the explicit call reaches Base::run. Actual: no Child-to-Base call edge, although the methods and inheritance exist. Renaming the child method to work() restores that edge. The synthesized Base-to-Child dispatch edge is a separate relationship.
Draft #2505 resolves the actual imported class and runtime extends parent, distinguishes static/instance methods, and preserves genuine recursion. Shadowed/reassigned aliases must not select project namesakes. This is constructor recovery, not complete typed/CJS alias or arbitrary dataflow analysis.
Review found two real draft regressions in parse-pool.test.ts (lines 130/132) that the earlier source-only call comparison missed. Both are corrected and covered by a regression test. Full call-site comparison on 893 public TS files now preserves all 35,465 baseline calls, including target, line and column. All 112 constructor/super tests pass with the native kernel active on Windows/Node 24. Performance results and limits are recorded in #2505.
Activity
Puma7 commentedon Oct 12, 2026
Updated validation after the supplied review:
Correction to the earlier no-loss claim: that comparison did not distinguish the actual top-level edge positions. Review found two lost pool call sites at parse-pool.test.ts:130/132; both are now restored and tested. Current #2505 preserves all 35,465 call-site tuples on the same 893 public TS files versus main 80e4b45, and passes all 112 native constructor/super cases. Source preprocessing is deferred until needed. The separate baseline shadowed-constructor lookup and broader typed/CJS aliases remain open work; details and measured limits are in the PR.
fix(js,ts): a super.method() call links to the method of the class's …
colbymchenry commentedon Oct 22, 2026
Thanks for the detailed report, @Puma7.
The first case,
item.show()on a receiver built from an aliased import, already resolves onmainsince #2661. We re-checked it with your fixture and a namesake class calledKnown.#2818 is merged to
mainand fixes the second: asuper.run()call now links to the method of the class's parent, or of the nearest ancestor that has it. A call in a static method reaches the parent's static method, and a parent from outside the project links nothing instead of a guessed namesake. On real projects that added about 640 correct links, for example in three.js, webpack and lit.Your #2505 was helpful guidance, and the changelog credits you for both. It ships in the next release.
fix(resolution): a super call in a class expression is not the enclos…
fix(resolution): a super call in a class expression is not the enclos…
fix(rust): a TS/JS super.method() call links to the method of the cla…