[Webkit-unassigned] [Bug 172031] [ESnext] Parsing Object Rest Destructuring isn't handle errors cases properly

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon May 15 10:51:08 PDT 2017


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

--- Comment #3 from Mark Lam <mark.lam at apple.com> ---
Comment on attachment 310139
  --> https://bugs.webkit.org/attachment.cgi?id=310139
Patch

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

> Source/JavaScriptCore/ChangeLog:17
> +        This patch is removing parseDestructuringPattern "kind" check when
> +        parsing rest destructuring (i.e when it proccess "..." token)
> +        and parseBindingOrAssignmentElement returns 0. This checks is
> +        redundant, because parseBindingOrAssignmentElement only can return
> +        null when "kind" is DestructuringKind::DestructureToExpressions. We
> +        can verify that looking at parseBindingOrAssignmentElement that falls
> +        to parseAssignmentElement when "kind == DestructuringKind::DestructureToExpressions"
> +        and to parseDestructuringPattern otherwise. In
> +        parseDestructuringPattern we can check that it onlys return 0 if
> +        kind == DestructuringKind::DestructureToExpressions.

I'm not sure that this is true.
1. If kind != DestructuringKind::DestructureToExpressions, parseBindingOrAssignmentElement() returns the result of parseDestructuringPattern().
2. In parseDestructuringPattern(),
    a. the OPENBRACKET case has a consumeOrFail that can return 0.
    b. the OPENBRACE case has failIfTrue, failIfTrueIfStrict, semanticFailIfTrue, etc. that can return 0.

These are just a few examples.  How did you prove that all of these (and other similar failout macros) are not also returning if kind != DestructuringKind::DestructureToExpressions

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


More information about the webkit-unassigned mailing list