You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
runtime: computed object-key write on a class prototype is invisible to instances and to the computed read #6945
Found while writing the #6941 regression suite (an assertion had to be dropped because of it). Not a GC bug — reproduces with zero allocation pressure.
A computed object key write onto a class prototype lands somewhere that instance lookup and the computed read cannot see. A plain string key works.
classC{m(): number{return1;}}constk: any={toString(): string{return"protoKey";}};(C.prototypeasany)[k]={tag: 6};console.log("computed via instance:",JSON.stringify((newC()asany).protoKey));console.log("computed direct:",JSON.stringify((C.prototypeasany).protoKey));console.log("computed via key obj:",JSON.stringify((C.prototypeasany)[k]));constplain: any={};plain[k]={tag: 7};console.log("plain:",JSON.stringify(plain.protoKey));
Node 26.5.0 (the pinned oracle):
computed via instance: {"tag":6}
computed direct: {"tag":6}
computed via key obj: {"tag":6}
plain: {"tag":7}
computed via instance: undefined <-- wrong
computed direct: {"tag":6}
computed via key obj: undefined <-- wrong
plain: {"tag":7}
So the write does land somewhere the staticC.prototype.protoKey read finds, but neither the instance prototype-chain lookup nor the computed read (C.prototype)[k] resolves it. Replacing k with the literal "protoKey" makes all three correct, so the difference is purely the computed/object-key path.
A closely related miss on the class-constructor (static) side, same file:
classC{statics(): number{return1;}}constk: any={toString(): string{return"statKey";}};(Casany)[k]={tag: 6};console.log("static via name:",JSON.stringify((Casany).statKey));// {"tag":6} okconsole.log("static via key obj:",JSON.stringify((Casany)[k]));// undefined wrong (node: {"tag":6})
Likely area: the class-ref (INT32 tag 0x7FFE) arms. The write side (js_object_set_property_key / js_dyn_index_set) routes class refs into the by-name setter and the static/CLASS_DYNAMIC_PROPS tables, but the computed read arm in js_dyn_index_get and the instance prototype-chain lookup do not appear to consult the same place for a coerced object key.
Activity
changelog: key #6945 fragment on PR #7134
fix(runtime): computed object keys on class proto and ClassRef (#6945) (