perf(linter): add codegen support for let statements before match

[camchenry]

Allows simple let statements before the match node.kind() return. For example:

let config = something;
match node.kind() {
  // use config and return
}

[camchenry]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• perf(linter): add codegen support for let statements before match #14678 👈 (View in Graphite)
• perf(linter): add codegen support for is_member_expression_kind in match #14677 : 1 other dependent PR (#14687 )
• 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 Performance Report

Merging #14678 will not alter performance

_{Comparing 10-16-perf_linter_add_codegen_support_for_let_statements_before_match (c2757a0) with 10-16-perf_linter_add_codegen_support_for_is_member_expression_kind_in_match (b30d1e2)}

Summary

✅ 4 untouched
⏩ 33 skipped¹

Footnotes

1. 33 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[camchenry]

sorry for hitting you up with so many of these PRs @camc314 😅 just been on a roll lately and figured I might as well try to squeeze all of the performance out of this one optimization if we can.

[overlookmotel]

Hmm. This one doesn't look quite as reliable as the others.

The init of a let statement could do anything, and that wouldn't be detected here. e.g.:

let _ = match node.kind() {
  AstKind::Function(_) => {
    ctx.diagnostic(...);
    return;
  }
  _ => {}
};

match node.kind() {
  AstKind::Class(_) => {
    ctx.diagnostic(...);
  }
  _ => {}
}

This would be identified as only matching Class, but in reality it also acts on Function.

That's a silly example, but I don't think it's out of the question that a pattern something like this could be used in reality.

It looks to me like the 2 rules that this affects could be refactored so this isn't necessary. Would that be a safer approach?

---

Just to say, you are ON FIRE with this stuff. It's brilliant. It's just this one which looks fishy to me.

[camchenry]

@overlookmotel oh good point. I'm too used to JavaScript still that I forgot you can just put an expression anywhere 😅

Yeah I'm gonna close this then. But I think it'll be safer to just refactor the lint rules manually. I've only been updating the linter codegen so that it's not quite so manual going forward, but this one's not too useful right now.