-
-
Notifications
You must be signed in to change notification settings - Fork 721
refactor(ast): add AstKind for ComputedMemberExpression
#11766
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
refactor(ast): add AstKind for ComputedMemberExpression
#11766
Conversation
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
CodSpeed Instrumentation Performance ReportMerging #11766 will improve performances by 14.65%Comparing Summary
Benchmarks breakdown
|
73d5ce7 to
f4ef54b
Compare
f4ef54b to
c424ef3
Compare
6e099bb to
3616da5
Compare
3616da5 to
48d83ab
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've made some comments below. Many relate to refactoring to deduplicate code which appears in both the branches for MemberExpression and ComputedMemberExpression.
But 3 of the comments relate to where I think the changes in this PR may alter behavior, and might have introduced bugs. Our test coverage in linter tends to be a little sparse, compared to the wide variety of wacky patterns which are legal JavaScript! So it's hard to rely on the tests.
#11767 is stacked on top of this and presumably touches much of the same code, so making changes in this PR would be a pain. And some of my comments may be rendered obsolete by #11767 anyway.
So I'm going to merge this now. But @camchenry could you possibly try to address any of my comments which are valid after these 2 PRs are merged?
| AstKind::ComputedMemberExpression(computed_prop_access_expr) => { | ||
| let prop_name = computed_prop_access_expr.static_property_name()?; | ||
| if prop_name != "prototype" { | ||
| return None; | ||
| } | ||
|
|
||
| if let AstKind::ChainExpression(_) = grandparent_node.kind() { | ||
| prototype_node = Some(grandparent_node); | ||
| if let Some(grandparent_parent) = ctx.nodes().parent_node(grandparent_node.id()) { | ||
| prototype_node = Some(grandparent_parent); | ||
| } | ||
| } | ||
| let grandparent_node = ctx.nodes().parent_node(parent.id())?; | ||
|
|
||
| if is_computed_member_expression_matching(grandparent_node, prop_access_expr) { | ||
| prototype_node = Some(grandparent_node); | ||
| } | ||
| if let AstKind::ChainExpression(_) = grandparent_node.kind() { | ||
| prototype_node = Some(grandparent_node); | ||
| if let Some(grandparent_parent) = ctx.nodes().parent_node(grandparent_node.id()) { | ||
| prototype_node = Some(grandparent_parent); | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't the parent of a ComputedMemberExpression always a MemberExpression?
So if let AstKind::ChainExpression(_) = grandparent_node.kind() will never match.
#11767 will remove AstKind::MemberExpression, which will fix it again. But it's worrying that this didn't cause any tests to fail. I suggest adding a test which fails due to this problem, fix it in this PR, and then we can make sure that test still passes after #11767.
Also, I think the code related to ChainExpression which is in both match arms could be de-duplicated by moving it to after the match (or maybe not worthwhile doing that if #11767 simplifies it again).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed my mind. Going to merge this now, but we should check after both PRs are merged that this didn't break anything.
Merge activity
|
48d83ab to
190e390
Compare
|
By the way, I hope you don't take my litany of comments as criticism. These |
|
Side note: Should we make |
) Follow up to comment in #11766 (comment)
Follow-up to some comments in #11766. This addresses an issue where we were not properly checking which side of assignment the prototype access occurred on.

AstKindconsistent #11490