feat(linter/eslint): add no_unreachable rule.

[rzvxa]

no-unreachable

oxlint-echosystem-ci result

This rule is done but since it is running for every possible statement and does quite a bit of work on them to determine whether it is 100% reachable or not; The performance in my opinion is kind of abysmal.

I'll try to work it out, I know Biome does 2 types of checks to simplify the rule for some nodes, However, they have a lot more false negatives than our implementation.

Here is one example of those false negatives

---

Update 1:

I've benchmarked this rule using only the simplified reachability checks and it was around 5% faster, To be honest, it isn't much improvement especially considering that we can only use this check for a small portion of nodes and even that is accompanied by newly introduced checks which would lessen the amount of performance gain further.

Most of the performance regression is because of allocations during our depth first search since we have to store both the visited and finished nodes which results in a bunch of rapid-fire allocations back to back. Currently, At the moment I don't have a great idea of how to improve it, We may have to implement our own graph to use arenas underneath.

Given that this rule is the most extensive use case of control flow (It doesn't come with a limited scope similar to property and constructor rules already implemented) this performance drop might be reasonable to some extent.

[graphite-app]

Your org has enabled the Graphite merge queue for merging into main

Add the label “merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix.

You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link.

[rzvxa]

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

• feat(linter/eslint): add no_unreachable rule. #3238 👈
• feat(semantic/cfg): add Condition instruction. #3567
• feat(semantic/cfg): add iteration instructions. #3566
• improvement(semantic/cfg): better control flow for switch statements. #3547
• improvement(semantic/cfg): rework error path. #3519
• improvement(semantic/cfg): better throw control flow. #3473
• improvement(linter/react): use CFG for detecting cyclic subgraphs in rules-of-hooks. #3454
• improvement(semantic/cfg): better CFG API #3472
• improvement(semantic/cfg): better break and continue flow. #3462
• improvement(semantic/cfg): better control flow for ForStatements. #3453
• improvement(semantic/cfg): better control flow for DoWhileStatements. #3452
• improvement(semantic/cfg): better control flow for WhileStatements. #3451
• improvement(semantic/cfg): rework basic blocks. #3381
• fix(linter): memorize visited block id in neighbors_filtered_by_edge_weight #3407
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @rzvxa and the rest of your teammates on Graphite

[codspeed-hq]

CodSpeed Performance Report

Merging #3238 will degrade performances by 22.18%

_{Comparing 05-11-feat_linter_eslint_add_no_unreachable_rule (6aa7af5) with 06-06-feat_semantic_cfg_add_condition_instruction (1644851)}

Summary

❌ 1 regressions
✅ 21 untouched benchmarks

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

Benchmarks breakdown

	Benchmark	06-06-feat_semantic_cfg_add_condition_instruction	05-11-feat_linter_eslint_add_no_unreachable_rule	Change
❌	linter[checker.ts]	1.3 s	1.6 s	-22.18%

[rzvxa]

@Boshen Can you read the first comment on this PR? I was wondering how much should I improve the performance to make it acceptable.

[Boshen]

@rzvxa Instead of doing the check inside the rule, are you able to mark the statement as unreachable during the cfg building phase inside semantic builder? For example add any of the following:

pub struct Semantic<'a> {
    pub unreachable: Vec<Span>, // All the unreachable spans
}

In the rule you just print out these spans in one go - a rule with only one line of code lol.

Or:

pub struct SemanticNode<'a> {
  pub unreachable: bool
}

Think outside of the box, we have the whole compiler pipeline, we can precompute a lot of stuff!

[rzvxa]

@rzvxa Instead of doing the check inside the rule, are you able to mark the statement as unreachable during the cfg building phase inside semantic builder? For example add any of the following:

pub struct Semantic<'a> {
    pub unreachable: Vec<Span>, // All the unreachable spans
}

In the rule you just print out these spans in one go - a rule with only one line of code lol.

Or:

pub struct SemanticNode<'a> {
  pub unreachable: bool
}

Think outside of the box, we have the whole compiler pipeline, we can precompute a lot of stuff!

Doesn't adding this to the semantic mean we have to pay for this cost in places where it isn't necessary? Not to mention the amount of code we have to add to our semantic builder to compute and determine the reachability.

I'm sure with this much performance regression even I wouldn't like my current results (and if it was my project I wouldn't allow it to merge) But having it in semantic doesn't feel right to me either. Maybe we can achieve a better performance by rewriting the rule to use run_once and compare reachablity in relation to the last rechable node instead of checking from function(or root) down.

For example if we visit an infinite loop we know for sure everything after this loop is unreachable, But in my current implementation we can't remember that information between nodes so we get to do it all over again.

[Boshen]

Yes, a run_once through the entire CFG can do the trick! Assuming you can query out the unreachable spans.

[Boshen]

In TypeScript, it marks nodes as unreachable via FlowFlags.Unreachable, and is queried in checker.ts by the function isReachableFlowNode, maybe we can draw some inspirations there 😅

[Boshen]

Maybe there's a bug somewhere? Or maybe you need to add some cache to the visited nodes?

checker.ts has some really complicated TypeScript code so maybe we hit an edge case somewhere.

[rzvxa]

In TypeScript, it marks nodes as unreachable via FlowFlags.Unreachable, and is queried in checker.ts by the function isReachableFlowNode, maybe we can draw some inspirations there 😅

We already have an unreachable instruction to mark the first unreachable block but it doesn't propagate and we use it to filter out the subgraph when walking through the flow, I assume they are doing all of our checks - if not more - to set these flags correctly. I'll give the typescript approach a read before making any major changes but I have a hunch that whatever approach we use to implement this rule it should get rid of our current redundant revisits either by running once or precomputing the information(which in of itself is another kind of run once happening in the core instead of linter crate).

It all brings me to the question I was going to ask before seeing this comment. Considering that this information can be reused but comes at the cost of more memory and overhead for everything using the semantics, Do you think having it there is going to be better overall?
Let's say we will have a 15% regression for the linter benchmark(which includes everything else so the number is higher than 15% if we pinpoint it to the linter itself) but if we do it in the semantic it would be faster let's say the time is cut in half and is 7% for the doing it in the semantic. It would make our linter benchmark to be 8% faster than the other approach but in return, it makes all of the other benchmarks to be about 7% slower; in reality, things like semantic benchmarks are going to get hit much greater than something like transformers - when they are all implemented - unless we heavily lean into feature-gating it.

[rzvxa]

Maybe there's a bug somewhere? Or maybe you need to add some cache to the visited nodes?

checker.ts has some really complicated TypeScript code so maybe we hit an edge case somewhere.

I know we are revisiting nodes over and over since we can't memorize the information from our run on the previous nodes, That's why I hope we get a great boost after getting rid of them, if I'm correct it would be something like going from around O(n^3) or even O(n!) in the worst case scenarios to around O(n^2).

[rzvxa]

The sad part is that all of our dfs paths are only 8% of the performance regression the other 12% is for the allocations these visits do.

[Boshen]

Do you think having it there is going to be better overall

We'll eventually make cfg construction optional at some point.

Regarding performance regression, I think we can accept around 10 - 15% given that we are doing a lot of work for cfg.

[rzvxa]

Regarding performance regression, I think we can accept around 10 - 15% given that we are doing a lot of work for cfg.

Just to be clear do you mean it is acceptable if we keep it in the semantics or are you talking about this rule alone?

[Boshen]

Regarding performance regression, I think we can accept around 10 - 15% given that we are doing a lot of work for cfg.

Just to be clear do you mean it is acceptable if we keep it in the semantics or are you talking about this rule alone?

Overall performance regression of 10 to 15%.

We can keep the unreachable query in the linter rule if that's what you prefer, I was only suggesting that maybe it's better to precompute in the semantic builder. I'll let you make the decision 😁