Share types (i.e., allow PathTypeHandlers) for properties with non-standard attributes (non-writable, etc.). #4118
Conversation
pleath
force-pushed
the
sharetypes-m
branch
5 times, most recently
from
85de59f to
5752595
Compare
|
|
||
| namespace Js | ||
| { | ||
| typedef uint8 SetterSlotIndex; |
There was a problem hiding this comment.
Maybe explicit naming this PathTypeHandlerSettingSlotIndex since this is only for PathTypeHandlers?
| virtual BOOL IsLockable() const override { return true; } | ||
| virtual BOOL IsSharable() const override { return true; } | ||
|
|
||
| static PropertyAttributes ObjectSlotAttributesToPropertyAttributes(const ObjectSlotAttributes attr) { return attr & ObjectSlotAttr_PropertyAttributesMask; } |
There was a problem hiding this comment.
ObjectSlotAttributesToPropertyAttributes [](start = 34, length = 40)
Could we add static asserts to ensure property attributes have the same corresponding bits in PropertyAttributes and ObjectSlotAttributes?
There was a problem hiding this comment.
Yeah, there are CompileAssert's in the cpp file.
There was a problem hiding this comment.
| PathTypeHandlerBase* GetRootPathTypeHandler(); | ||
|
|
||
| virtual ObjectSlotAttributes * GetAttributeArray() const { return nullptr; } | ||
| virtual ObjectSlotAttributes GetAttributeArray(const PropertyIndex index) const { return ObjectSlotAttr_Default; } |
There was a problem hiding this comment.
GetAttributeArray [](start = 37, length = 17)
This is returning the attributes for a particular property index, right? If so, can we rename it to GetAttributes?
Proposing similar change for GetSetterSlots below.
There was a problem hiding this comment.
Oh, right. That's what I had originally; didn't mean to change it. I'll change it back.
pleath
force-pushed
the
sharetypes-m
branch
2 times, most recently
from
45a8241 to
d28fde3
Compare
|
|
||
| if (instance->HasObjectArray()) | ||
| { | ||
| requestContext->GetOrAddPropertyRecord(propertyName, propertyNameLength, &propertyRecord); |
There was a problem hiding this comment.
use propertyNameString directly? #3875 adds PropertyString and LiteralStringWithPropertyStringPtr check.
There was a problem hiding this comment.
Thanks. This is actually a copy of some very old logic. Should we change it everywhere?
|
LGTM |
…andard attributes (non-writable, etc.). This change draws on Kount Veluri's work on behalf of native fields. It adds a wrinkle to the type path mechanism, replacing the PropertyId successor map key with a key that munges PropertyId and attributes. The way is paved for sharing types with getter/setters, deleted properties, and native values. When a property's attributes are changed/set, the type path is branched starting with the type that precedes the one that introduced the property.
…properties with non-standard attributes (non-writable, etc.). Merge pull request #4118 from pleath:sharetypes-m This change draws on Kount Veluri's work on behalf of native fields. It adds a wrinkle to the type path mechanism, replacing the PropertyId successor map key with a key that munges PropertyId and attributes. The way is paved for sharing types with getter/setters, deleted properties, and native values. When a property's attributes are changed/set, the type path is branched starting with the type that precedes the one that introduced the property.
…te non-config props in strict mode)
… slots Rename ThrowCantDelete and fix regression from chakra-core#4118 (delete non-config props in strict mode)
5 participants
This change draws on Kount Veluri's work on behalf of native fields. It adds a wrinkle to the type path mechanism, replacing the PropertyId successor map key with a key that munges PropertyId and attributes. The way is paved for sharing types with getter/setters, deleted properties, and native values. When a property's attributes are changed/set, the type path is branched starting with the type that precedes the one that introduced the property.