fix(semantic): correctly visit IfStmt test when building cfg

[camc314]

This PR fixes the construction of the cfg within oxc_semantic, by marking the test of IfStatement as unconditionally visited.

Given the following:

if (foo) {
  bar();
} else {
  baz();
}

Would produce the following graph:

graph TD
    0["bb0"]
    1["bb1 IfStatement"]
    2["bb2 Condition(IdentifierReference(foo))"]
    3["bb3 BlockStatement ExpressionStatement"]
    4["bb4 BlockStatement ExpressionStatement"]
    5["bb5"]

    1 -- "Error(Implicit)" --> 0
    2 -- "Error(Implicit)" --> 0
    3 -- "Error(Implicit)" --> 0
    4 -- "Error(Implicit)" --> 0
    5 -- "Error(Implicit)" --> 0
    1 -- "Normal" --> 2
    1 -- "Normal" --> 4
    3 -- "Normal" --> 5
    2 -- "Jump" --> 3
    4 -- "Normal" --> 5

Loading

After this change, it produces the following graph:

graph TD
    0["bb0"]
    1["bb1 IfStatement"]
    2["bb2 Condition(IdentifierReference(foo))"]
    3["bb3 BlockStatement ExpressionStatement"]
    4["bb4 BlockStatement ExpressionStatement"]
    5["bb5"]

    1 -- "Error(Implicit)" --> 0
    2 -- "Error(Implicit)" --> 0
    3 -- "Error(Implicit)" --> 0
    4 -- "Error(Implicit)" --> 0
    5 -- "Error(Implicit)" --> 0
    1 -- "Normal" --> 2
    3 -- "Normal" --> 5
    2 -- "Jump" --> 3
    2 -- "Jump" --> 4
    4 -- "Normal" --> 5

Loading

Rather than jumping from the if statment (bb1\nIfStatement) directly to the consequent (bb4 BlockStatement ExpressionStatement), it now unconditionally visits the test of the if statement. This can be seen in the after graph as the jump to bb4 BlockStatement ExpressionStatement" comes from bb2 Condition(IdentifierReference(foo)) rather than from bb1 IfStatement.

As a result of this change, rules_of_hooks, does not have false positives when a hook is in a position such as:

if (useMe) {

As the cfg would previously think that useMe was called conditionally when in fact it was not

fixes #9795
related #9807

[camc314]

• fix(semantic): correctly visit IfStmt test when building cfg #9864 👈 (View in Graphite)
• 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 #9864 will not alter performance

_{Comparing c/03-18-fix_semantic_correctly_visit_ifstmt_test_when_building_cfg (3d4c5f3) with main (544a090)}

Summary

✅ 33 untouched benchmarks

[camc314]

cc @hulin32 hopefully that description makes sense

[hulin32]

@camc314 thx a lot for your explanation.

This part I understood. Need to look into it to get more ideas.

[Boshen]

Merge activity

• Mar 18, 9:06 PM EDT: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Mar 18, 9:06 PM EDT: A user added this pull request to the Graphite merge queue.
• Mar 18, 9:14 PM EDT: A user merged this pull request with the Graphite merge queue.