<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [test262] Fixing mapped arguments object property test case"
href="https://bugs.webkit.org/show_bug.cgi?id=159398#c78">Comment # 78</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [test262] Fixing mapped arguments object property test case"
href="https://bugs.webkit.org/show_bug.cgi?id=159398">bug 159398</a>
from <span class="vcard"><a class="email" href="mailto:ticaiolima@gmail.com" title="Caio Lima <ticaiolima@gmail.com>"> <span class="fn">Caio Lima</span></a>
</span></b>
<pre>Comment on <span class=""><a href="attachment.cgi?id=294029&action=diff" name="attach_294029" title="Patch">attachment 294029</a> <a href="attachment.cgi?id=294029&action=edit" title="Patch">[details]</a></span>
Patch
View in context: <a href="https://bugs.webkit.org/attachment.cgi?id=294029&action=review">https://bugs.webkit.org/attachment.cgi?id=294029&action=review</a>
<span class="quote">>> 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.</span >
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;
<span class="quote">>> 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?</span >
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>