[Webkit-unassigned] [Bug 159398] [test262] Fixing mapped arguments object property test case

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=159398

--- Comment #78 from Caio Lima <ticaiolima at gmail.com> ---
Comment on attachment 294029
  --> https://bugs.webkit.org/attachment.cgi?id=294029
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=294029&action=review

>> Source/JavaScriptCore/runtime/GenericArgumentsInlines.h:62
>> +    if (index && thisObject->canAccessIndexQuickly(index.value()))
> 
> Why can we ever access an index quickly if we've modified an argument at that index? This seems weird to me.

I tried to explain it on ChangeLog.

In this new implementation, canAccessIndexQuickly actually returns if the index is still mapped. When it happens, we need to return property slot with value of "thisObject->getIndexQuickly(index.value())" and with Base::getOwnPropertySlot value. Dos it make sense?

I have 2 things in mind to make it clear:

1. Change canAccessIndexQuickly to isIndexMapped;
2. Explain it with a comment;

>> Source/JavaScriptCore/runtime/GenericArgumentsInlines.h:232
>> +            // property from arguments object are {writable: true, configurable: true, enumerable: true} by default
> 
> What if we modify configurable/enumuerable? Should we also stop mapping in such a scenario?
> I'm confused why we have two vectors: modified/overrides. Can you explain why we need two of them?

I also tried to explain it on ChangeLog. I am going to try make it more clear.

The point is that the old implementation is using overrides to keep track if the index is still mapped and also if its property descriptor was changed in some way. The problem of this approach is that Mapping rules aren't related with property descriptor changes and we need different mechanism to keep track of them, since a property can still be mapped, even its descriptor has changed. In other words, we stop mapping as soon as a property descriptor is changed, however there are some cases that this mapping should continue happening (e.g. when we change configurable or enumerable to false, for example). One test case that is keeping track of this behavior is JSTests/stress/arguments-bizarre-behaviour-disable-enumerability.js.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161106/30a60f4a/attachment-0001.html>