perf(linter): detect node types from let..else statements

[camchenry]

• part of linter: dynamically skip running rules that do not have the relevant node types #12223

Adds basic detection for syntax like let AstKind::Something(...) = node.kind() else { return }; in lint rules for generating rule runner trait impls.

Correctness

Spot checking it on my laptop shows same number of diagnostics for kibana and vscode:

Benchmarks

~15% faster on oven-sh/bun:

~9% faster on microsoft/vscode:

~11% faster on posthog/posthog:

~8% faster on elastic/kibana:

[camchenry]

• perf(linter): detect node types from let..else statements #13690 👈 (View in Graphite)
• refactor(linter_codegen): split into separate files #13657
• 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 #13690 will improve performances by 45.05%

_{Comparing 09-11-perf_linter_detect_node_types_from_let.else_statements (90c8286) with main (6b74078)¹}

Summary

⚡ 4 improvements
✅ 33 untouched

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
⚡	linter[RadixUIAdoptionSection.jsx]	2.4 ms	1.7 ms	+45.05%
⚡	linter[binder.ts]	142.1 ms	99.1 ms	+43.37%
⚡	linter[cal.com.tsx]	1,165.4 ms	835.4 ms	+39.51%
⚡	linter[react.development.js]	50.4 ms	35.7 ms	+41.08%

Footnotes

1. No successful run was found on main (90c8286) during the generation of this report, so 6b74078 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[Copilot]

Pull Request Overview

This PR enhances the linter codegen performance by adding detection for let..else statement patterns when analyzing lint rules. The purpose is to extract node types from let AstKind::Something(...) = node.kind() else { return }; patterns in addition to the existing if..else pattern detection, enabling more precise rule runner trait implementations.

Key changes:

• Adds a new LetElseDetector to complement the existing IfElseKindDetector
• Updates the main detection logic to try both detectors sequentially
• Modifies some existing lint rules to use the optimized let..else pattern

Reviewed Changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
tasks/linter_codegen/src/main.rs	Integrates LetElseDetector and updates detection logic to try both detectors
tasks/linter_codegen/src/let_else_detector.rs	Implements new detector for let..else AST node type patterns
crates/oxc_linter/src/rules/unicorn/consistent_date_clone.rs	Converts from reference pattern to direct pattern matching
crates/oxc_linter/src/rules/react/no_unknown_property.rs	Converts from reference pattern to direct pattern matching
crates/oxc_linter/src/rule.rs	Updates test cases to verify correct node type detection

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[camc314]

@camchenry Amazing work!!

does this make our codspeed benchmarks not very representative of the real world any more, since we aren't actally runnint the linter on them?

[camc314]

Merge activity

• Sep 12, 4:03 AM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Sep 12, 4:03 AM UTC: camc314 added this pull request to the Graphite merge queue.
• Sep 12, 4:08 AM UTC: Merged by the Graphite merge queue.

[camchenry]

@camc314 They were never truly representative of the real-world, since they run with all rules and plugins enabled which is pretty much never true in reality. It should make the CodSpeed benchmarks more sensitive to smaller changes in the linter though, since we're not measuring as many no-op rules anymore.