WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
159226
get_by_id_with_this does not trigger a to_this in caller.
https://bugs.webkit.org/show_bug.cgi?id=159226
Summary
get_by_id_with_this does not trigger a to_this in caller.
Keith Miller
Reported
2016-06-28 13:59:01 PDT
Created
attachment 282281
[details]
bad test case. run the attached test and it will throw an exception, which it should not.
Attachments
bad test case.
(173 bytes, application/x-javascript)
2016-06-28 13:59 PDT
,
Keith Miller
no flags
Details
patch
(6.13 KB, patch)
2016-06-30 12:33 PDT
,
Saam Barati
no flags
Details
Formatted Diff
Diff
patch
(9.23 KB, patch)
2016-06-30 14:52 PDT
,
Saam Barati
keith_miller
: review+
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Saam Barati
Comment 1
2016-06-30 12:33:39 PDT
Created
attachment 282456
[details]
patch
Keith Miller
Comment 2
2016-06-30 12:35:37 PDT
Comment on
attachment 282456
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=282456&action=review
> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:554 > + } else if (functionNode->usesThis() || codeBlock->usesEval() || isThisUsedInInnerArrowFunction() || functionNode->usesSuperProperty()) {
Can you tell if we are inside an object literal vs a class? If so, maybe we should only emit the to_this if we are in an object literal. Otherwise file a bug?
Keith Miller
Comment 3
2016-06-30 12:36:32 PDT
Comment on
attachment 282456
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=282456&action=review
>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:554 >> + } else if (functionNode->usesThis() || codeBlock->usesEval() || isThisUsedInInnerArrowFunction() || functionNode->usesSuperProperty()) { > > Can you tell if we are inside an object literal vs a class? If so, maybe we should only emit the to_this if we are in an object literal. Otherwise file a bug?
Or even better, only do it if the code is strict.
Keith Miller
Comment 4
2016-06-30 12:36:48 PDT
non-strict*
Saam Barati
Comment 5
2016-06-30 12:39:06 PDT
(In reply to
comment #4
)
> non-strict*
I lied about the only case that matters is non-strict to strict. Both directions matter. Whenever strictness of callee vs caller are different, there will be user observable effects.
Saam Barati
Comment 6
2016-06-30 12:39:24 PDT
(In reply to
comment #5
)
> (In reply to
comment #4
) > > non-strict* > > I lied about the only case that matters is non-strict to > strict. Both directions matter. Whenever strictness of callee > vs caller are different, there will be user observable effects.
I'll add a test for this.
Saam Barati
Comment 7
2016-06-30 12:54:05 PDT
(In reply to
comment #2
)
> Comment on
attachment 282456
[details]
> patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=282456&action=review
> > > Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:554 > > + } else if (functionNode->usesThis() || codeBlock->usesEval() || isThisUsedInInnerArrowFunction() || functionNode->usesSuperProperty()) { > > Can you tell if we are inside an object literal vs a class? If so, maybe we > should only emit the to_this if we are in an object literal. Otherwise file > a bug?
After thinking about it more, I don't think this is sound. You don't know if you're definitely calling a strict method, even if you're in a class because you can muck with the super class' prototype after it's been constructed. I'll verify that this is correct by adding a test.
Saam Barati
Comment 8
2016-06-30 13:53:03 PDT
(In reply to
comment #5
)
> (In reply to
comment #4
) > > non-strict* > > I lied about the only case that matters is non-strict to > strict. Both directions matter. Whenever strictness of callee > vs caller are different, there will be user observable effects.
Actually, I think I'm wrong. We only care if the caller is not-strict. If the caller is strict, and callee is not strict, we don't need to to_this for a super property access.
Saam Barati
Comment 9
2016-06-30 13:55:07 PDT
(In reply to
comment #7
)
> (In reply to
comment #2
) > > Comment on
attachment 282456
[details]
> > patch > > > > View in context: > >
https://bugs.webkit.org/attachment.cgi?id=282456&action=review
> > > > > Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:554 > > > + } else if (functionNode->usesThis() || codeBlock->usesEval() || isThisUsedInInnerArrowFunction() || functionNode->usesSuperProperty()) { > > > > Can you tell if we are inside an object literal vs a class? If so, maybe we > > should only emit the to_this if we are in an object literal. Otherwise file > > a bug? > > After thinking about it more, I don't think this is sound. > You don't know if you're definitely calling a strict method, > even if you're in a class because you can muck with the super > class' prototype after it's been constructed. I'll verify > that this is correct by adding a test.
This is sound, given my previous comment that strict to not-strict doesn't need to to_this for super property access.
Saam Barati
Comment 10
2016-06-30 14:52:00 PDT
Created
attachment 282472
[details]
patch
WebKit Commit Bot
Comment 11
2016-06-30 14:54:27 PDT
Attachment 282472
[details]
did not pass style-queue: ERROR: Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:554: One line control clauses should not use braces. [whitespace/braces] [4] Total errors found: 1 in 5 files If any of these errors are false positives, please file a bug against check-webkit-style.
Keith Miller
Comment 12
2016-06-30 14:59:00 PDT
Comment on
attachment 282472
[details]
patch r=me
Keith Miller
Comment 13
2016-06-30 15:00:20 PDT
Comment on
attachment 282472
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=282472&action=review
> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:552 > } else if (constructorKind() != ConstructorKind::None) {
You should get rid of these braces though.
Saam Barati
Comment 14
2016-06-30 15:07:27 PDT
landed in:
http://trac.webkit.org/changeset/202710
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug