PropertyAttribute needs a CustomValue bit.
https://bugs.webkit.org/show_bug.cgi?id=191993
<rdar://problem/46264467>
Reviewed by Saam Barati.
JSTests:
- stress/regress-191993.js: Added.
Source/JavaScriptCore:
This is because GetByIdStatus needs to distinguish CustomValue properties from
other types, and its only means of doing so is via the property's attributes.
Previously, there's nothing in the property's attributes that can indicate that
the property is a CustomValue.
We fix this by doing the following:
- Added a PropertyAttribute::CustomValue bit.
- Added a PropertyAttribute::CustomAccessorOrValue convenience bit mask that is
CustomAccessor | CustomValue.
- Since CustomGetterSetter properties are only set via JSObject::putDirectCustomAccessor(),
we added a check in JSObject::putDirectCustomAccessor() to see if the attributes
bits include PropertyAttribute::CustomAccessor. If not, then the property
must be a CustomValue, and we'll add the PropertyAttribute::CustomValue bit
to the attributes bits.
This ensures that the property attributes is sufficient to tell us if the
property contains a CustomGetterSetter.
- Updated all checks for PropertyAttribute::CustomAccessor to check for
PropertyAttribute::CustomAccessorOrValue instead if their intent is to check
for the presence of a CustomGetterSetter as opposed to checking specifically
for one that is used as a CustomAccessor.
This includes all the Structure transition code that needs to capture the
attributes change when a CustomValue has been added.
- Filtered out the PropertyAttribute::CustomValue bit in PropertyDescriptor.
The fact that we're using a CustomGetterSetter as a CustomValue should remain
invisible to the descriptor. This is because the descriptor should describe
a CustomValue no differently from a plain value.
- Added some asserts to ensure that property attributes are as expected, and to
document some invariants.
- bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::GetByIdStatus::computeFor):
- bytecode/InByIdStatus.cpp:
(JSC::InByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
- bytecode/PropertyCondition.cpp:
(JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
- bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
(JSC::getCalculatedDisplayName):
(JSC::JSObject::putDirectCustomAccessor):
(JSC::JSObject::putDirectNonIndexAccessor):
(JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
(JSC::JSObject::putDirectIndex):
(JSC::JSObject::fillCustomGetterPropertySlot):
(JSC::JSObject::putDirect):
- runtime/JSObjectInlines.h:
(JSC::JSObject::putDirectInternal):
- runtime/PropertyDescriptor.cpp:
(JSC::PropertyDescriptor::setDescriptor):
(JSC::PropertyDescriptor::setCustomDescriptor):
(JSC::PropertyDescriptor::setAccessorDescriptor):
(JSC::PropertySlot::setCustomGetterSetter):
Source/WebCore:
This patch revealed a bug in the CodeGenerator where a constructor property is
set with a ReadOnly attribute. This conflicts with the WebIDL link (see clause
12 in https://heycam.github.io/webidl/#interface-prototype-object) which states
that it should be [Writable]. The ReadOnly attribute is now removed.
On the WebCore side, this change is covered by existing tests.
- bindings/scripts/CodeGeneratorJS.pm:
(GenerateImplementation):
- bindings/scripts/test/JS/JSTestCustomConstructorWithNoInterfaceObject.cpp:
(WebCore::jsTestCustomConstructorWithNoInterfaceObjectConstructor):