Summary
super inside computed object/class accessors and methods resolves through the current prototype chain, including after Object.setPrototypeOf.
Affected Test262 rows
Perry actual behavior from report
- 1 x runtime-fail: Uncaught exception:
object.a() returns 'a proto m', after executing Object.setPrototypeOf(object, proto); Expected SameValue(«"a0"», «"a proto m"») to be true
- 1 x runtime-fail: Uncaught exception: The value of
object.a is 'a proto m'. Defined as get ['a']() { return 'a' + super.m(); } Expected SameValue(«"a0"», «"a proto m"») to be true
- 1 x runtime-fail: Uncaught exception: The value of
value is 'a 2', after executing object.a = 2; Expected SameValue(«0», «"a 2"») to be true
Node / ECMAScript expected behavior
super inside computed object/class accessors and methods resolves through the current prototype chain, including after Object.setPrototypeOf.
Likely subsystem
runtime prototype chain / HIR super-member lowering
Acceptance criteria
- Computed getter/setter/method
super.m() rows return the same values as Node.
- Prototype mutations visible to ordinary object methods are visible to computed
super paths.
- Existing direct non-computed
super behavior does not regress.
Validation
Run the Test262 differential against the affected area and confirm these rows leave the gap report:
scripts/test262_subset.py --root vendor/test262 --dir language/computed-property-names/object/accessor language/computed-property-names/object/method --sample-cap 99999 --report /tmp/COMPUTED_SUPER.json
This is Perry language/runtime semantics triage, not a Node core API compatibility issue.
Summary
superinside computed object/class accessors and methods resolves through the current prototype chain, including afterObject.setPrototypeOf.Affected Test262 rows
object.ais'a proto m'. Defined asget ['a']() { return 'a' + super.m(); }Expected SameValue(«"a0"», «"a proto m"») to be true)valueis'a 2', after executingobject.a = 2;Expected SameValue(«0», «"a 2"») to be true)object.a()returns'a proto m', after executingObject.setPrototypeOf(object, proto);Expected SameValue(«"a0"», «"a proto m"») to be true)Perry actual behavior from report
object.a()returns'a proto m', after executingObject.setPrototypeOf(object, proto);Expected SameValue(«"a0"», «"a proto m"») to be trueobject.ais'a proto m'. Defined asget ['a']() { return 'a' + super.m(); }Expected SameValue(«"a0"», «"a proto m"») to be truevalueis'a 2', after executingobject.a = 2;Expected SameValue(«0», «"a 2"») to be trueNode / ECMAScript expected behavior
superinside computed object/class accessors and methods resolves through the current prototype chain, including afterObject.setPrototypeOf.Likely subsystem
runtime prototype chain / HIR super-member lowering
Acceptance criteria
super.m()rows return the same values as Node.superpaths.superbehavior does not regress.Validation
Run the Test262 differential against the affected area and confirm these rows leave the gap report:
This is Perry language/runtime semantics triage, not a Node core API compatibility issue.