-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[gardening] Standardize SILBasicBlock successor/predecessor methods that deal with blocks rather than the full successor data structure to have the suffix 'Block'. #5939
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@swift-ci Please test |
Build failed |
The linux failure is a type checker issue. I do not know why it is failing with this commit which only affects SIL. I am going to try one more time to see if it is non-deterministic and then I am going to wait to see if the Linux builders hit this. |
@swift-ci Please test linux platform |
Ah ok, it is non-determinstic. CodeFi is fixing it in dfa3723. |
…hat deal with blocks rather than the full successor data structure to have the suffix 'Block'. This was already done for getSuccessorBlocks() to distinguish getting successor blocks from getting the full list of SILSuccessors via getSuccessors(). This commit just makes all of the successor/predecessor code follow that naming convention. Some examples: getSingleSuccessor() => getSingleSuccessorBlock(). isSuccessor() => isSuccessorBlock(). getPreds() => getPredecessorBlocks(). Really, IMO, we should consider renaming SILSuccessor to a more verbose name so that it is clear that it is more of an internal detail of SILBasicBlock's implementation rather than something that one should consider as apart of one's mental model of the IR when one really wants to be thinking about predecessor and successor blocks. But that is not what this commit is trying to change, it is just trying to eliminate a bit of technical debt by making the naming conventions here consistent.
274c301
to
38ec08f
Compare
I rebased ontop of his commit. Lets do this again... |
@swift-ci Please test and merge |
1 similar comment
@swift-ci Please test and merge |
Build failed |
@gottesmm Anything that can be done about the LLDB test that has been failing in the full test suite for a while now? |
@swift-ci Please smoke test linux platform |
@CodaFi I imagine that it should be disabled until the LLDB team has time to look at it. @llvm-beanz @tfiala thoughts? |
@swift-ci Please smoke test linux platform |
[gardening] Standardize SILBasicBlock successor/predecessor methods that deal with blocks rather than the full successor data structure to have the suffix 'Block'.
This was already done for getSuccessorBlocks() to distinguish getting successor
blocks from getting the full list of SILSuccessors via getSuccessors(). This
commit just makes all of the successor/predecessor code follow that naming
convention.
Some examples:
getSingleSuccessor() => getSingleSuccessorBlock().
isSuccessor() => isSuccessorBlock().
getPreds() => getPredecessorBlocks().
Really, IMO, we should consider renaming SILSuccessor to a more verbose name so
that it is clear that it is more of an internal detail of SILBasicBlock's
implementation rather than something that one should consider as apart of one's
mental model of the IR when one really wants to be thinking about predecessor
and successor blocks. But that is not what this commit is trying to change, it
is just trying to eliminate a bit of technical debt by making the naming
conventions here consistent.