## Summary This PR re-introduces the control-flow graph implementation which was first introduced in #5384, and then removed in #9463 due to not being feature complete. Mainly, it lacked the ability to process `try`-`except` blocks, along with some more minor bugs. Closes #8958 and #8959 and #14881. ## Overview of Changes I will now highlight the major changes implemented in this PR, in order of implementation. 1. Introduced a post-processing step in loop handling to find any `continue` or `break` statements within the loop body and redirect them appropriately. 2. Introduced a loop-continue block which is always placed at the end of loop blocks, and ensures proper looping regardless of the internal logic of the block. This resolves #8958. 3. Implemented `try` processing with the following logic (resolves #8959): 1. In the example below the cfg first encounters a conditional `ExceptionRaised` forking if an exception was (or will be) raised in the try block. This is not possible to know (except for trivial cases) so we assume both paths can be taken unconditionally. 2. Going down the `try` path the cfg goes `try`->`else`->`finally` unconditionally. 3. Going down the `except` path the cfg will meet several conditional `ExceptionCaught` which fork depending on the nature of the exception caught. Again there's no way to know which exceptions may be raised so both paths are assumed to be taken unconditionally. 4. If none of the exception blocks catch the exception then the cfg terminates by raising a new exception. 5. A post-processing step is also implemented to redirect any `raises` or `returns` within the blocks appropriately. ```python def func(): try: print("try") except Exception: print("Exception") except OtherException as e: print("OtherException") else: print("else") finally: print("finally") ``` ```mermaid flowchart TD start(("Start")) return(("End")) block0[["`*(empty)*`"]] block1["print(#quot;finally#quot;)\n"] block2["print(#quot;else#quot;)\n"] block3["print(#quot;try#quot;)\n"] block4[["Exception raised"]] block5["print(#quot;OtherException#quot;)\n"] block6["try: print(#quot;try#quot;) except Exception: print(#quot;Exception#quot;) except OtherException as e: print(#quot;OtherException#quot;) else: print(#quot;else#quot;) finally: print(#quot;finally#quot;)\n"] block7["print(#quot;Exception#quot;)\n"] block8["try: print(#quot;try#quot;) except Exception: print(#quot;Exception#quot;) except OtherException as e: print(#quot;OtherException#quot;) else: print(#quot;else#quot;) finally: print(#quot;finally#quot;)\n"] block9["try: print(#quot;try#quot;) except Exception: print(#quot;Exception#quot;) except OtherException as e: print(#quot;OtherException#quot;) else: print(#quot;else#quot;) finally: print(#quot;finally#quot;)\n"] start --> block9 block9 -- "Exception raised" --> block8 block9 -- "else" --> block3 block8 -- "Exception" --> block7 block8 -- "else" --> block6 block7 --> block1 block6 -- "OtherException" --> block5 block6 -- "else" --> block4 block5 --> block1 block4 --> return block3 --> block2 block2 --> block1 block1 --> block0 block0 --> return ``` 6. Implemented `with` processing with the following logic: 1. `with` statements have no conditional execution (apart from the hidden logic handling the enter and exit), so the block is assumed to execute unconditionally. 2. The one exception is that exceptions raised within the block may result in control flow resuming at the end of the block. Since it is not possible know if an exception will be raised, or if it will be handled by the context manager, we assume that execution always continues after `with` blocks even if the blocks contain `raise` or `return` statements. This is handled in a post-processing step. ## Test Plan Additional test fixtures and control-flow fixtures were added. --------- Co-authored-by: Micha Reiser <micha@reiser.io> Co-authored-by: dylwil3 <dylwil3@gmail.com>

Control-flow graph fails to connect body-to-loop when loop is the last statement #8958

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions