perf(linter): generate node type info for lint rules with let..else

[camchenry]

No description provided.

[camchenry]

• perf(linter): skip iterating nodes for jest-only rules #13303
• perf(linter): skip running on symbols and jest nodes for node-only rules #13302
• perf(linter): extract node types from more rules #13300
• perf(linter): filter out rules which have no relevant node types in file #13297
• perf(linter): generate node type info for lint rules with let..else #13287 👈 (View in Graphite)
• perf(linter): skip rules that do not have any relevant node types #13138 : 1 other dependent PR (#13573 )
• 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 #13287 will improve performances by 71.95%

_{Comparing 08-25-perf_linter_generate_node_type_info_for_lint_rules_with_let.else_ (918b957) with main (2f9a6ac)¹}

Summary

⚡ 4 improvements
✅ 30 untouched benchmarks

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
⚡	linter[RadixUIAdoptionSection.jsx]	2.6 ms	1.5 ms	+71.95%
⚡	linter[binder.ts]	147.6 ms	87.4 ms	+68.9%
⚡	linter[cal.com.tsx]	1,215 ms	739.9 ms	+64.22%
⚡	linter[react.development.js]	52.6 ms	32.6 ms	+61.49%

Footnotes

1. No successful run was found on 08-16-wip_skip_rules_that_do_not_have_any_relevant_node_types (52a4734) during the generation of this report, so main (2f9a6ac) was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[overlookmotel]

Is this check enough? This is a contrived example, but something like this would produce the wrong result:

let is_var_decl = matches!(node.kind(), AstKind::VariableDeclaration(_));
for ancestor_kind in ctx.ancestor_kinds(node.id()) {
    if matches!(ancestor_kind, AstKind::Function(_)) {
        if is_var_decl {
            ctx.diagnostic( /* ... */ );
            return;
        }
        break;
    }
}

let AstKind::Class(decl) = node.kind() else { return };

Maybe safer to bail out if let AstKind::Blah(_) = node.kind() else { return }; isn't the first statement.

Once all the common patterns are all covered, we'll be able to see which rules remain that aren't being identified, and match on more patterns to catch them.

i.e. start conservative and expand from there, rather than risk false positives from being too liberal initially.