-
Notifications
You must be signed in to change notification settings - Fork 41
get_start_control_flow_node, next_from_end, raise edges, and labels in branches #6
Conversation
dbieber
commented
Oct 6, 2021
•
edited
Loading
edited
- Adds get_start_control_flow_node to ControlFlowGraph
- Adds next_from_end to ControlFlowNode
- Uses labels (e.g. '' and '' strings) to indicate these special nodes
- Support keyword only arguments without defaults
- Add non-interrupting edges from raise statements
- Bump version number
def get_start_control_flow_node(self): | ||
if self.start_block.control_flow_nodes: | ||
return self.start_block.control_flow_nodes[0] | ||
if self.start_block.exits_from_end: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the second if-branch means: "if self.start_block
has no control_flow_nodes
, check its exits_from_end
successor blocks to determine a start control flow node".
Could you please share some examples when this second if-branch is relevant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here are two examples:
Example A
try:
L1
except:
L2
Example B
while 1:
L2
Example B is clearer to me. The condition 1
does not get merged with the <start>
block because there is an incoming edge to the condition that should not go to <start>
(if it did, that would indicate the program is starting again.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think in Example A L1 doesn't get merged with <start>
because raising from L1 leads to a different location than raising from <start>
would.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In fact, we never merge a block with the start block (maybe for the reason in my last comment.)
The only way additional statements end up in the start block is if they are placed there directly during cfg construction. This happens when the program starts with a sequence of simple statements.