perf(linter): skip rules that do not have any relevant node types

[camchenry]

• part of linter: dynamically skip running rules that do not have the relevant node types #12223
• supersedes stack: perf(linter): add should_run based on node types (batch 1) #12228

This PR adds the ability to add node type information to indicate what node types a lint rule acts on. The lint rule runner can use this information to optimize running lint rules by skipping nodes, files, or rules that don't apply.

This is a simple version that is focused on creating the framework for automatically generating the rule runner code. This is not the end of optimizations. Currently only 102 rules have node type information, while 471 rules have no node type information and will not be skipped. Adding node type information for more rules will improve performance. We may also be able to skip more nodes and files by being clever about how we use this information. For example, filtering out any rules which do not run on any node type, if the file contains no relevant node types for the rule.

• Adds a new RuleRunner trait which includes information needed for indicating whether a rule has node type info or not
• Adds a oxc_linter_codegen task which is used to generate the implementation of RuleRunner trait for all lint rules. This is mostly written by AI, so worth a bit of skepticism, but I've tried to manually verify the results and it looks good (just lacking more complex detection).
  • Currently, only rules that contain a single top-level if statement (or chain of else if), or a single match statement will have their node type info generated. This should give us a high level of confidence, since these patterns are relatively easy to verify and identify, but it's only a subset of all rules. Next steps will be to add support for let...else
• Adjusts the main linting loop to use the node type information to skip rules for node types that don't apply
• Updates CI to include a check for any uncommitted linter codegen changes

---

Benchmarks

In the latest version of this PR, CodSpeed shows an up to +13% increase in linter performance across large and small files. In the real-world, I've seen a ~5-15% improvement in performance, but in some cases close to zero for very small files. In either case, there appears to be little downside and a lot of potential upside here.

[camchenry]

• perf(linter): skip rules that do not have any relevant node types #13138 : 2 dependent PRs (#13287 , #13573 ) 👈 (View in Graphite)
• feat(semantic): add ability to lookup if AST contains any node kinds #13137
• 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 #13138 will improve performances by 4.93%

_{Comparing 08-16-wip_skip_rules_that_do_not_have_any_relevant_node_types (a744aff) with main (bccc276)¹}

Summary

⚡ 4 improvements
✅ 33 untouched benchmarks

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
⚡	linter[RadixUIAdoptionSection.jsx]	2.6 ms	2.4 ms	+4.93%
⚡	linter[binder.ts]	148 ms	141.9 ms	+4.34%
⚡	linter[cal.com.tsx]	1.2 s	1.2 s	+4.37%
⚡	linter[react.development.js]	52.6 ms	50.3 ms	+4.43%

Footnotes

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

[Dunqing]

What an unbelievable performance improvement!

[Boshen]

Insane!

[overlookmotel]

Superb!

Probably you intend to do this anyway, but I think need to use syn to parse the rule files. The regex may be, for example, missing the else branch in patterns like this:

if let AstKind::Function(func) = node.kind() {
    // ...
} else if let AstKind::ArrowFunctionExpression(arrow) = node.kind() {
    // ...
}

If it's currently missing out some types, that may slow things down a little.

On the other hand, some patterns aren't currently being caught by the regex, like this one:

let Some(ss) = node.kind().as_switch_statement() else { return };

(from no_duplicate_case rule)

Matching those would take more rules out of the "any type" category, and speed things up even more!

---

I've made a few small comments about the AstTypesIter iterator, but that's just fiddling at the edges.

---

Edit 7/9/25: This PR has been scaled back a lot from the original. The first version showed ~90% perf improvement. For anyone wondering, that's the reason for all our "amazing perf!" comments.

[overlookmotel]

Merge activity

• Sep 7, 7:53 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 7, 7:55 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 8, 3:18 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 8, 3:18 AM UTC: camc314 added this pull request to the Graphite merge queue.
• Sep 8, 3:27 AM UTC: Merged by the Graphite merge queue.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.