-
barraclough@apple.com authored
PropertySlot::setValue is ambiguous Reviewed by Geoff Garen. There are three different versions of PropertySlot::setValue, one for cacheable properties, and two that are used interchangeably and inconsistently. The problematic variants are the ones that just take a value, and one that takes a value and also the object containing the property. Unify on always providing the object, and remove the version that just takes a value. This always works except for JSString, where we optimize out the object (logically we should be instantiating a temporary StringObject on every property access). Provide a version of setValue that takes a JSString as the owner of the property. We won't store this, but it makes it clear that this interface should only be used from JSString. * API/JSCallbackObjectFunctions.h: (JSC::::getOwnPropertySlot): * JSCTypedArrayStubs.h: * runtime/Arguments.cpp: (JSC::Arguments::getOwnPropertySlotByIndex): (JSC::Arguments::getOwnPropertySlot): * runtime/JSActivation.cpp: (JSC::JSActivation::symbolTableGet): (JSC::JSActivation::getOwnPropertySlot): * runtime/JSArray.cpp: (JSC::JSArray::getOwnPropertySlot): * runtime/JSObject.cpp: (JSC::JSObject::getOwnPropertySlotByIndex): * runtime/JSString.h: (JSC::JSString::getStringPropertySlot): * runtime/JSSymbolTableObject.h: (JSC::symbolTableGet): * runtime/SparseArrayValueMap.cpp: (JSC::SparseArrayEntry::get): - Pass object containing property to PropertySlot::setValue * runtime/PropertySlot.h: (JSC::PropertySlot::setValue): - Logically, the base of a string property access is a temporary StringObject, but we optimize that away. (JSC::PropertySlot::setUndefined): - removed setValue(JSValue), added setValue(JSString*, JSValue) git-svn-id: http://svn.webkit.org/repository/webkit/trunk@154113 268f45cc-cd09-0410-ab3c-d52691b4dbfc
c6cf7cb0