Bug 151595 - [JSC] support CoverInitializedName in nested AssignmentPatterns
Summary: [JSC] support CoverInitializedName in nested AssignmentPatterns
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-24 21:37 PST by Caitlin Potter (:caitp)
Modified: 2015-12-01 14:47 PST (History)
7 users (show)

See Also:


Attachments
[JSC] support CoverInitializedName in nested AssignmentPatterns (8.56 KB, patch)
2015-11-24 21:39 PST, Caitlin Potter (:caitp)
no flags Details | Formatted Diff | Diff
[JSC] support CoverInitializedName in nested AssignmentPatterns (8.51 KB, patch)
2015-12-01 11:36 PST, Caitlin Potter (:caitp)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Caitlin Potter (:caitp) 2015-11-24 21:37:19 PST
[JSC] support CoverInitializedName in nested AssignmentPatterns
Comment 1 Caitlin Potter (:caitp) 2015-11-24 21:39:12 PST
Created attachment 266144 [details]
[JSC] support CoverInitializedName in nested AssignmentPatterns

A regression introduced in bug https://bugs.webkit.org/show_bug.cgi?id=151026 causes the parser to fail when attempting to parse nested ObjectAssignmentPatterns with CoverInitializedName destructuring targets. This change fixes this by propagating the ExpressionErrorClass to the parent classifier when parsing properties and elements
Comment 2 Caitlin Potter (:caitp) 2015-11-25 06:11:52 PST
Comment on attachment 266144 [details]
[JSC] support CoverInitializedName in nested AssignmentPatterns

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

> Source/JavaScriptCore/tests/es6/destructuring_assignment_nested_cover_initialized_name.js:3
> +    ({ a: { b: { c = "it worked" } } } = { a: { b: {} } });

To explain the regression, we now parse as an expression first, and fallback on the assignment pattern parsing if it's an object literal followed by an `=`. In this case, when initially parsing the outer ObjectLiteral as an Expression, the error occurs on the inner ObjectLiteral, and it's not followed by an `=`, so an error is reported, but the error class does not indicate that the error allows reparsing as a Pattern.

the change communicates the error class to the outer classifier, so that nested pattern errors can be handled properly by parseAssignmentExpression
Comment 3 Geoffrey Garen 2015-11-30 14:05:33 PST
Comment on attachment 266144 [details]
[JSC] support CoverInitializedName in nested AssignmentPatterns

r=me
Comment 4 Caitlin Potter (:caitp) 2015-12-01 11:36:24 PST
Created attachment 266373 [details]
[JSC] support CoverInitializedName in nested AssignmentPatterns

Rebased
Comment 5 Caitlin Potter (:caitp) 2015-12-01 11:39:23 PST
Comment on attachment 266373 [details]
[JSC] support CoverInitializedName in nested AssignmentPatterns

meant to CQ the other patch last week, it probably won't apply on the bots now, so rebased
Comment 6 WebKit Commit Bot 2015-12-01 14:47:14 PST
Comment on attachment 266373 [details]
[JSC] support CoverInitializedName in nested AssignmentPatterns

Clearing flags on attachment: 266373

Committed r192919: <http://trac.webkit.org/changeset/192919>
Comment 7 WebKit Commit Bot 2015-12-01 14:47:19 PST
All reviewed patches have been landed.  Closing bug.