[ic] fix handling of existing properties in Define{Keyed|Named}OwnIC
- When the property being defined with DefineKeyedOwnIC or DefineNamedOwnIC already exists, we should use the slow path to check if the operation is allowed in case the property is non-configurable or Object.preventExtensions() has been called on the property. - Since KeyedStoreIC:Store() reuses StoreIC::Store() when the key is a name, we should use Runtime::DefineObjectOwnProperty() for DefineKeyedOwnIC too. - When dealing with public fields, Runtime::DefineObjectOwnProperty() should use JSReceiver::CreateDataProperty() instead of Object::SetProperty() for the specified semantics. This patch also adds JSReceiver::AddPrivateField() for it and StoreIC::Store to define private fields without triggering traps or checking extensibility. - To emit a more specific error message when redefining properties on non-extensible objects, Object::AddDataProperty() now also takes a EnforceDefineSemantics enum to distinguish between set and define. - Drive-by: fix JSReceiver::CheckIfCanDefine() which should check for extensibility even if the configurability check passes. Bug: chromium:1259950, v8:9888 Change-Id: Ib1bc851ffd4b9c3a0e98cac96dafe743c08ee37e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3517934Reviewed-by:Shu-yu Guo <syg@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#79603}
Showing
This diff is collapsed.
Please
register
or
sign in
to comment