refactor(ast): add AstKind for AssignmentTargetPropertyIdentifier, AssignmentTargetPropertyProperty

[camc314]

No description provided.

[camc314]

• refactor(ast): add AstKind for AssignmentTargetPropertyIdentifier, AssignmentTargetPropertyProperty #11985 👈 (View in Graphite)
• refactor(ast): add AstKind for AssignmentTargetRest #11984
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

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-hq]

CodSpeed Instrumentation Performance Report

Merging #11985 will degrade performances by 13.36%

_{Comparing c/06-30-refactor_ast_add_astkind_for_assignmenttargetpropertyidentifier_assignmenttargetpropertyproperty_ (f7a2ae4) with main (cfa52c2)}

Summary

❌ 1 regressions
✅ 37 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
❌	mangler[cal.com.tsx]	3.1 ms	3.5 ms	-13.36%

[camchenry]

Looks good. One general comment I have after looking at these rules is that we should come up with some better abstractions for getting/checking ancestor state. Seems like something that shows up in a lot of rules, and is tricky to implement well. I'm sure there's also some perf opportunities there too.

[camc314]

Looks good. One general comment I have after looking at these rules is that we should come up with some better abstractions for getting/checking ancestor state. Seems like something that shows up in a lot of rules, and is tricky to implement well. I'm sure there's also some perf opportunities there too.

definitly, I think with our codegen, we could also do something like

impl <some node> {
  fn parent(&self, nodes) -> some enum
}

where some enum is correctly narrowed based on the type of the node the fn parent function has

[camc314]

Merge activity

• Jun 30, 8:27 PM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Jun 30, 8:27 PM UTC: camc314 added this pull request to the Graphite merge queue.
• Jun 30, 8:36 PM UTC: Merged by the Graphite merge queue.