Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[v10.x] deps: V8: backport cd21f71f9cb5 #33862

Closed
wants to merge 1 commit into from

Conversation

targos
Copy link
Member

@targos targos commented Jun 13, 2020

Original commit message:

[parser] Validate destructuring assignment pattern in correct classifier

Previously we'd first accumulate errors to the parent and validate the
destructuring pattern in the parent. In the case of ParseArguments this
will invalidly propagate binding pattern errors from one argument to the
next. The reason why ParseArguments keeps track of binding pattern errors
is because it could also be used to parse async arrow function parameters.
If we see async(a,b) we don't yet know whether this is the head of an
async arrow function, or a call to async with arguments a and b.

Bug: v8:8241
Change-Id: I670ab9a9c6f2e0bee399808b02a465ae1afa7c3f
Reviewed-on: https://chromium-review.googlesource.com/c/1296229
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56887}

Refs: v8/v8@cd21f71
Fixes: #23142

Original commit message:

    [parser] Validate destructuring assignment pattern in correct classifier

    Previously we'd first accumulate errors to the parent and validate the
    destructuring pattern in the parent. In the case of ParseArguments this
    will invalidly propagate binding pattern errors from one argument to the
    next. The reason why ParseArguments keeps track of binding pattern errors
    is because it could also be used to parse async arrow function parameters.
    If we see async(a,b) we don't yet know whether this is the head of an
    async arrow function, or a call to async with arguments a and b.

    Bug: v8:8241
    Change-Id: I670ab9a9c6f2e0bee399808b02a465ae1afa7c3f
    Reviewed-on: https://chromium-review.googlesource.com/c/1296229
    Commit-Queue: Toon Verwaest <verwaest@chromium.org>
    Reviewed-by: Marja Hölttä <marja@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#56887}

Refs: v8/v8@cd21f71
Fixes: nodejs#23142
@nodejs-github-bot nodejs-github-bot added build Issues and PRs related to build files or the CI. v10.x v8 engine Issues and PRs related to the V8 dependency. labels Jun 13, 2020
@targos
Copy link
Member Author

targos commented Jun 16, 2020

/cc @nodejs/lts

Comment on lines 2986 to 2987
if (is_destructuring_assignment) {
ValidateAssignmentPattern(CHECK_OK);
} else {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:(

(I guess we should keep the empty if block on the off chance we'd need to backport anything else onto this file in the future.)

@MylesBorins
Copy link
Member

Is this important enough for a maintenance release? Seems like this parser error has existed as long as 10.x has

@targos
Copy link
Member Author

targos commented Jun 16, 2020

Maybe not, but if there is a release for another reason, why not include this with it?

@MylesBorins
Copy link
Member

Should be fine to land on staging and if there is a future maintenance release to fix non security stuff we can ship it.

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

nodejs-github-bot commented Jul 1, 2020

richardlau pushed a commit that referenced this pull request Jul 1, 2020
Original commit message:

    [parser] Validate destructuring assignment pattern in correct classifier

    Previously we'd first accumulate errors to the parent and validate the
    destructuring pattern in the parent. In the case of ParseArguments this
    will invalidly propagate binding pattern errors from one argument to the
    next. The reason why ParseArguments keeps track of binding pattern errors
    is because it could also be used to parse async arrow function parameters.
    If we see async(a,b) we don't yet know whether this is the head of an
    async arrow function, or a call to async with arguments a and b.

    Bug: v8:8241
    Change-Id: I670ab9a9c6f2e0bee399808b02a465ae1afa7c3f
    Reviewed-on: https://chromium-review.googlesource.com/c/1296229
    Commit-Queue: Toon Verwaest <verwaest@chromium.org>
    Reviewed-by: Marja Hölttä <marja@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#56887}

Refs: v8/v8@cd21f71
Fixes: #23142

PR-URL: #33862
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
@richardlau
Copy link
Member

Landed in 3acc89f.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Issues and PRs related to build files or the CI. v8 engine Issues and PRs related to the V8 dependency.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants