Simplify the return path analysis

[jjcnn]

Description

The return path analysis ensures that if a method must return a value then the spine of the method returns a value. The analysis traverses a linearized version of the CFG (one which ignores branching expressions such as if-then-else and loops, and simply treats them as a single node) of each method from the (unique) entry point to the (unique) exit point. If there is ever a node in the graph that does not have outgoing edges, then an error is thrown.

When constructing such a linearized CFG we have so far treated local impls as branches, meaning that the spine was in fact not linear:

fn main() -> u64 {
   // This point has two outgoing edges

   // One goes to here
    impl core::ops::Eq for X {
        fn eq(self, other: Self) -> bool {
            asm(r1: self, r2: other, r3) {
                eq r3 r2 r1;
                r3: bool
            }
        }
    }

    // The other goes to here
    if X::Y(true) == X::Y(true) {
        a
    } else {
        a
    }
}

This has been the case even though the edge into a local impl does not in fact represent legal control flow.

This incorrect construction has made the traversal of the spine-CFG very convoluted and difficult to follow.

This PR fixes the incorrect construction, and simplifies the traversal of the spine so that it is clear what is going on. I have also added an additional test to show that methods inside local impls are in fact analyzed separately, even though there is no longer an edge going into the impl from the surrounding function.

Checklist

• I have linked to any relevant issues.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation where relevant (API docs, the reference, and the Sway book).
  • If my change requires substantial documentation changes, I have requested support from the DevRel team
• I have added tests that prove my fix is effective or that my feature works.
• I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[codspeed-hq]

CodSpeed Performance Report

Merging #6541 will not alter performance

_{Comparing jjcnn/return_path_analysis_exit_fix (2285dcf) with master (be70774)}

Summary

✅ 22 untouched benchmarks

[IGI-111]

Can we test this to validate some previously unhandled state at least?

[jjcnn]

Can we test this to validate some previously unhandled state at least?

I haven't been able to find an example where the old algorithm gave an incorrect result. I can keep looking if you want?

When I removed the rovers[0] != exit_point check I got an error in this test case (as well as in a number of others):

https://github.com/FuelLabs/sway/tree/master/test/src/e2e_vm_tests/test_programs/should_pass/language/enum_in_fn_decl

That's the one I used to debug my algorithm.

[jjcnn]

@IGI-111 : I managed to fix the linearization problem, and the traversal algorithm is much cleaner now. Take a look at your convenience.