-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[SILOptimizer] Don't diagnose infinite recursion if a branch terminates the program #19724
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
[SILOptimizer] Don't diagnose infinite recursion if a branch terminates the program #19724
Conversation
// Note that this check happens _before_ the recursion check. This is | ||
// deliberate, as we want to ignore recursive calls inside a program | ||
// termination point. | ||
if (isARCInertTrapBB(curBlock)) |
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.
Can you rename this in this commit to is program termination point? Since we are expanding the use of this I would suggest that we also rename the semantics string to something more descriptive since this is no longer used just for ARC.
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.
Might as well move it out of ARCAnalysis and into SILBasicBlock, eh?
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.
Also, I think we should include something about the lack of side effects in the name, moreso than isProgramTerminationPoint
would...
if (curBlock->getTerminator()->isFunctionExiting()) | ||
TermInst *terminator = curBlock->getTerminator(); | ||
if (terminator->isFunctionExiting() || | ||
terminator->getTermKind() == TermKind::UnreachableInst) |
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.
If you are going to go this way can you move this into a separate query function and exhaustive switch over term kind so that if people add a new weird terminator they know to update this?
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.
lgtm for the std lib part
@gottesmm I've renamed |
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.
3 nits and then LGTM.
lib/SIL/SILBasicBlock.cpp
Outdated
@@ -336,6 +337,79 @@ bool SILBasicBlock::isEntry() const { | |||
return this == &*getParent()->begin(); | |||
} | |||
|
|||
//===----------------------------------------------------------------------===// | |||
// Leaking BB Analysis |
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.
Can you change all of the references here to ARC/Leaking BBs/etc to refer to trapping block analysis/etc. I'll show you the ones that I see.
lib/SIL/SILBasicBlock.cpp
Outdated
} | ||
|
||
// Otherwise, we have an unreachable and every instruction is inert from an | ||
// ARC perspective in an unreachable BB. |
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.
lib/SIL/SILBasicBlock.cpp
Outdated
return false; | ||
} | ||
|
||
/// Match a call to a trap BB with no ARC relevant side effects. |
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. Also this shouldn't be a doxygen comment (so 2 slashes).
This patch augments the infinite recursion checker to not warn if a branch terminates, but still warns if a branch calls into something with `@_semantics("arc.programtermination_point")`. This way, calling `fatalError` doesn't disqualify you for the diagnostic, but calling `exit` does. This also removes the warning workaround in the standard library, and annotates the internal _assertionFailure functions as `programtermination_point`s, so they get this treatment too.
f94910b
to
c1bee86
Compare
@swift-ci please test |
(I also want to make sure this doesn't introduce any new warnings) @swift-ci please test source compatibility |
Build failed |
Build failed |
So, interestingly, this warning happens in the source compatibility suite, and has been happening for as far back as there are still build logs (before #19693).
And I think this is another false positive related to dynamic dispatch, similar to SR-7925 |
Release source compat run failed while cloning Vapor, but I'm satisfied with the results from the debug run. @gottesmm Good to merge? |
Let err rip. |
This is causing failures. See rdar://45080912. Backing out. |
…es (swiftlang#19724) This patch augments the infinite recursion checker to not warn if a branch terminates, but still warns if a branch calls into something with `@_semantics("arc.programtermination_point")`. This way, calling `fatalError` doesn't disqualify you for the diagnostic, but calling `exit` does. This also removes the warning workaround in the standard library, and annotates the internal _assertionFailure functions as `programtermination_point`s, so they get this treatment too.
…terminates (swiftlang#19724)" This reverts commit e94450e. rdar://45080912
This patch augments the infinite recursion checker to not warn if a
branch terminates, but still warns if a branch calls into something with
@_semantics("arc.programtermination_point")
. This way, callingfatalError
doesn't disqualify you for the diagnostic, but calling
exit
does.This also removes the warning workaround in the standard library, and
annotates the internal _assertionFailure functions as
programtermination_point
s, so they get this treatment too.