[Webkit-unassigned] [Bug 163208] [ES6]. Implement Annex B.3.3 function hoisting rules for eval

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Dec 12 01:12:19 PST 2016


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

Saam Barati <sbarati at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #296084|review?                     |review-
              Flags|                            |

--- Comment #17 from Saam Barati <sbarati at apple.com> ---
Comment on attachment 296084
  --> https://bugs.webkit.org/attachment.cgi?id=296084
Patch

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

> Source/JavaScriptCore/bytecode/CodeBlock.cpp:2876
> +        // Fixme: we do not have llint optimization for those op_codes

Please file a bug for this if you think we should do it. That said, this is way more than a LLInt optimization, knowing which scope you'll resolve to helps in all tiers.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:769
> +    for (FunctionMetadataNode* function : evalNode->functionStack()) {
> +        VarKind kind = varKind(function->ident().impl());
> +        if (kind == VarKind::Scope)
> +            m_codeBlock->addFunctionDecl(makeFunction(function));
> +        else
> +            m_functionsToInitialize.append(std::make_pair(function, GlobalFunctionVariable));
> +    }

Do you mind elaborating on your previous example for why you said this is needed, I don't quite get it.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2193
> +    // resolve_scope dst, id, ResolveType, skipLocalScope

This comment is wrong. It has the wrong bytecode name.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2208
> +    // resolve_scope dst, scope id

Ditto.

> Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:1109
> +                ASSERT_NOT_REACHED();
> +                break;

This feels wrong, AI should be able to handle a constant you don't expect. That said, I think this only allows for scope arguments, however, I think this would break if a `with` scope or some other scope was the argument to this. It seems totally possible that other scopes can be your constant argument here.

> Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:2848
> +    case ResolveClosestVarScope:

You also need a rule for IsVarScopeType here.
Did this not cause any issues for you? If seems like it should lead to a crash, so please add a test that stresses this.

> Source/JavaScriptCore/dfg/DFGNode.h:994
> +    int32_t skipScope()
> +    {
> +        return m_opInfo2.as<int32_t>();
> +    }

should be uint32_t

> Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm:2118
> +    loadisFromInstruction(4, t0)

I don't think this is needed.

> Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm:2124
> +    loadisFromInstruction(4, t0)

Ditto

> Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:2069
> +    loadisFromInstruction(4, t0)

ditto

> Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:2075
> +    loadisFromInstruction(4, t0)

ditto

-- 
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/20161212/b9b9ad9e/attachment.html>


More information about the webkit-unassigned mailing list