Repository navigation
Own property named prototype is silently dropped when written through a function parameter (and after a dynamic-key write) #9365
Description
Activity
Minimised further — no function call and no parameter needed. Three lines:
const o = {}; o["x" + 1] = 1; // a computed-key write o.prototype = { m: 7 }; // silently dropped console.log(Object.prototype.hasOwnProperty.call(o, "prototype")); // node: true perry: false
Replacing the computed key with a static one makes it work:
const o = {}; o.x1 = 1; // static key o.prototype = { m: 7 }; console.log(Object.prototype.hasOwnProperty.call(o, "prototype")); // both: true
So the trigger is precisely: one computed-key write ahead of it is enough to make a later
o.prototype = vstore go nowhere. That subsumes the parameter case in the issue body (a parameter is just another way for the receiver's static type to stop being a known plain object).The read side is fine, for what it is worth — I checked
.prototypereads through a function parameter, at a polymorphic call site, and inside a static method after a computed-key write, a symbol-keyed write, a chained symbol write and a plain static-property write onthis; all eight are node-identical. It is specifically the store that is discarded.Scoped precisely. After one computed-key write on a plain object, I stored under seven names, each both ways (statically named
o.k = vand computedo[k] = v) — 14 stores. Exactly one is dropped:store perry o.prototype = v(static name)DROPPED o["prototype"] = v(computed)kept o.foo/o.constructor/o.name/o.length/o.caller/o.arguments(static)kept the same six, computed kept So it is not "dynamic-shaped receivers lose stores" and not "special names are mishandled". It is specifically the statically-named
.prototypestore, which codegen presumably routes to the function/class prototype slot; when the receiver's shape is no longer statically a plain object, that store lands nowhere and the ordinary own-property path is never taken. The computed form escapes because it cannot take that specialised route.That also explains why the parameter case in the issue body fails: a parameter is simply another receiver whose static type is not a known plain object.
Repro (4 lines)
The write is silently dropped — no throw, no warning.
osimply never gains the property:hasOwnPropertyisfalse,Object.keys(o)does not list it, andObject.getOwnPropertyDescriptor(o, "prototype")returnsundefined.What distinguishes the failing shape
Eleven variants, all writing an own
prototypeonto a plain object. Only the parameter write fails:function f(){const o={};o.prototype=V;return o}(local)const o={};o.prototype=V(same scope){prototype:V}object literalo["prototype"]=VObject.defineProperty(o,"prototype",…){...{prototype:V}}/Object.assign({},{prototype:V})(function(t){t.prototype=V})(o)— write through a parameterA second failing shape, same family, where the receiver is a local whose shape has been made dynamic first:
This one fails for every
n, includingn = 0(the loop never runs). So it is not about property count or overflow slots — the mere presence of the dynamic-key write is enough to change how the latero.prototype = …is compiled.The unifying pattern in both: when the receiver's static type is not known to be a plain object,
x.prototype = vappears to be routed to the function/class prototype slot rather than to an ordinary own property, and for a plain object that store goes nowhere.Why this matters beyond the fixture
This is the mechanism family behind #9341 (
cc --helpdown on main). The diagnostic there shows the failing call isObject.defineProperty(undefined, "getContentType", …), where theundefinediszin axios'si.e. a
.prototypeaccess on a receiver of imprecise static type yieldingundefinedinstead of the prototype. The read side and the write side above are the same fragility. #9341's trigger is a regression inside83754818e..main(this write-drop reproduces identically on the green83754818ebuild, so it is not itself the regression) — but a.prototypeaccess that silently answersundefinedon an imprecisely-typed receiver is the machinery that regression is landing on, and hardening it would make that whole class of failure loud instead of silent.At minimum, a store that cannot be honoured should not be discarded in silence.
Found while bisecting #9341; verified pre-existing on
83754818e(#9242) anda03be729c(#9336) — byte-identical failure on both.