Bug 87755 - Fix scoping bug involving eval, with, and optimized non-locals
Summary: Fix scoping bug involving eval, with, and optimized non-locals
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Andy Wingo
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-29 10:02 PDT by Andy Wingo
Modified: 2012-05-29 12:09 PDT (History)
3 users (show)

See Also:


Attachments
Patch (5.86 KB, patch)
2012-05-29 10:08 PDT, Andy Wingo
msaboff: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Wingo 2012-05-29 10:02:56 PDT
Bug 76285 introduced a regression in the handling of dynamic scope lookup.  Bug 87158 reports the regression, but it is being used for some other purpose.  The patch to be attached fixes bug 87158.
Comment 1 Andy Wingo 2012-05-29 10:08:20 PDT
Created attachment 144577 [details]
Patch
Comment 2 Michael Saboff 2012-05-29 11:40:32 PDT
Comment on attachment 144577 [details]
Patch

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

This fix seems a little like a band-aid.  Shouldn't isDynamicScope() return true for scope chain objects that are dynamic and require runtime resolution?  Then the code would break out of the loop at we'd generate the right resolve opcode.

My comment to open a new defect was incorrect.  I think we should close out this defect as no change. We should land the reviewed patch in https://bugs.webkit.org/show_bug.cgi?id=87158 on trunk.  A new defect should be opened or the original refactoring defect should be reopened for your suggested fix or variations.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:1173
> +    size_t depthOfFirstScopeWithDynamicChecks = 0;

Why can't the logic for depth be modified so that it provides the right answer?

Shouldn't this variable's name really indicate the depth before the first scope with dynamic checks?

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:1207
> +                ++depthOfFirstScopeWithDynamicChecks;

If there are multiple scope chain nodes that require dynamic checks, won't this be set to the depth before the last one?

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:1220
>          if ((flags & ResolveResult::DynamicFlag) && depth)
>              return ResolveResult::dynamicGlobalResolve(depth, scope);

Doesn't this code also need the depth before the first dynamic check?
Comment 3 Andy Wingo 2012-05-29 12:09:33 PDT
(In reply to comment #2)
> (From update of attachment 144577 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=144577&action=review
> 
> This fix seems a little like a band-aid.  Shouldn't isDynamicScope() return true for scope chain objects that are dynamic and require runtime resolution?  Then the code would break out of the loop at we'd generate the right resolve opcode.

Michael, re
> 
> My comment to open a new defect was incorrect.  I think we should close out this defect as no change. We should land the reviewed patch in https://bugs.webkit.org/show_bug.cgi?id=87158 on trunk.  A new defect should be opened or the original refactoring defect should be reopened for your suggested fix or variations.
> 
> > Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:1173
> > +    size_t depthOfFirstScopeWithDynamicChecks = 0;
> 
> Why can't the logic for depth be modified so that it provides the right answer?
> 
> Shouldn't this variable's name really indicate the depth before the first scope with dynamic checks?
> 
> > Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:1207
> > +                ++depthOfFirstScopeWithDynamicChecks;
> 
> If there are multiple scope chain nodes that require dynamic checks, won't this be set to the depth before the last one?
> 
> > Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:1220
> >          if ((flags & ResolveResult::DynamicFlag) && depth)
> >              return ResolveResult::dynamicGlobalResolve(depth, scope);
> 
> Doesn't this code also need the depth before the first dynamic check?