[swift-dev] Renaming SILSuccessor -> SILCFGEdge

[John McCall]

> On Apr 26, 2017, at 6:11 PM, Michael Gottesman <mgottesman at apple.com> wrote:
>> On Apr 26, 2017, at 1:44 PM, John McCall <rjmccall at apple.com> wrote:
>> 
>>> On Apr 26, 2017, at 4:24 PM, Michael Gottesman via swift-dev <swift-dev at swift.org> wrote:
>>> Hey everyone.
>>> 
>>> I am currently doing some small fixes to SILSuccessor (adding some comments and fixing some issues exposed by LLVM upstream). As I read the code it became pretty apparent that the name is a misnomer... SILSuccessor is not just representing a successor, rather it is representing a whole CFG edge. This can be seen in how SILSuccessor is used to iterate over the predecessors of the block.
>>> 
>>> With that in mind, I would like to rename SILSuccessor to SILCFGEdge. It will make it much clearer without knowing any context what this data structure is used for.
>>> 
>>> Any objections, disagreements, flames, etc?
>> 
>> It seems a little unnecessary to me.  The successor relationship is an edge, and all the edges of the local CFG are successor relationships.  I guess it looks a little funny that the edges into a block are represented by "successors", but I think when you think about it it makes sense.
> 
> IMO this is more of an issue than something "looking funny". Using code named "successor" to look up the "predecessors" of a block is misleading and results in unnecessary cognitive overhead for the reader who has to "think about it" for it to make sense.

Uh, sure, but this is also not something most people have to deal with a ton, and it's a learn-once-and-remember sort of thing.

>> "SILCFGEdge" is also not a very attractive name because of the two abbreviations.  If you had a nice alternative to "CFGEdge" that was less biased to the beginning/end (like Successor/Predecessor are), I probably wouldn't object.
> 
> Ok. Maybe SILControlFlowEdge?

A bit elaborate, but it could work.  Honestly, this is not a type I have to write out much.

John.