Back out patch for bug 469625, it mysteriously busts stuff.

This commit is contained in:
Brendan Eich
2008-12-19 01:38:09 -08:00
parent e399803b66
commit 7294cf7d01
5 changed files with 8 additions and 37 deletions

View File

@@ -326,20 +326,10 @@ js_SetProtoOrParent(JSContext *cx, JSObject *obj, uint32 slot, JSObject *pobj)
return JS_FALSE;
}
/*
* Maintain the "any Array prototype has indexed properties hazard" flag by
* conservatively setting it. We simply don't know what pobj has in the way
* of indexed properties, either directly or along its prototype chain, and
* we won't expend effort here to find out. We do know that if obj is not
* an array or a prototype (delegate), then we're ok. And, of course, pobj
* must be non-null.
*
* This pessimistic approach could be improved, but setting __proto__ is
* quite rare and arguably deserving of deoptimization.
*/
// Maintain the "any Array prototype has indexed properties hazard" flag.
if (slot == JSSLOT_PROTO &&
pobj &&
(OBJ_IS_ARRAY(cx, obj) || OBJ_IS_DELEGATE(cx, obj))) {
OBJ_IS_ARRAY(cx, pobj) &&
pobj->fslots[JSSLOT_ARRAY_LENGTH] != 0) {
rt->anyArrayProtoHasElement = JS_TRUE;
}
return JS_TRUE;
@@ -3171,9 +3161,6 @@ js_DefineProperty(JSContext *cx, JSObject *obj, jsid id, jsval value,
* nominal initial value of a slot-full property, while GC safety wants that
* value to be stored before the call-out through the hook. Optimize to do
* both while saving cycles for classes that stub their addProperty hook.
*
* As in js_SetProtoOrParent (see above), we maintain the "any Array prototype
* has indexed properties hazard" flag by conservatively setting it.
*/
#define ADD_PROPERTY_HELPER(cx,clasp,obj,scope,sprop,vp,cleanup) \
JS_BEGIN_MACRO \
@@ -3187,8 +3174,6 @@ js_DefineProperty(JSContext *cx, JSObject *obj, jsid id, jsval value,
LOCKED_OBJ_WRITE_BARRIER(cx, obj, (sprop)->slot, *(vp)); \
} \
} \
if (STOBJ_IS_DELEGATE(obj) && JSID_IS_INT(sprop->id)) \
cx->runtime->anyArrayProtoHasElement = JS_TRUE; \
JS_END_MACRO
JSBool