Skip to content

[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

Merged

Conversation

harlanhaskins
Copy link
Contributor

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_points, so they get this treatment too.

@harlanhaskins harlanhaskins changed the title [SILOptimizer] Don't diagnose infinite recursion if a branch terminates [SILOptimizer] Don't diagnose infinite recursion if a branch terminates the program Oct 5, 2018
// 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))
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor Author

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)
Copy link
Contributor

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?

Copy link
Member

@airspeedswift airspeedswift left a 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

@harlanhaskins
Copy link
Contributor Author

@gottesmm I've renamed isARCInertTrap to SILBasicBlock::isProgramTerminationPoint but I think that name isn't descriptive enough. Thoughts? I've also renamed arc.programtermination_point to just programtermination_pointbut I need to go through and rearrange it in the docs to move it out of the 'strictly ARC' section.

Copy link
Contributor

@gottesmm gottesmm left a 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.

@@ -336,6 +337,79 @@ bool SILBasicBlock::isEntry() const {
return this == &*getParent()->begin();
}

//===----------------------------------------------------------------------===//
// Leaking BB Analysis
Copy link
Contributor

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.

}

// Otherwise, we have an unreachable and every instruction is inert from an
// ARC perspective in an unreachable BB.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here.

return false;
}

/// Match a call to a trap BB with no ARC relevant side effects.
Copy link
Contributor

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.
@harlanhaskins harlanhaskins force-pushed the past-the-point-of-no-return branch from f94910b to c1bee86 Compare October 5, 2018 21:02
@harlanhaskins
Copy link
Contributor Author

@swift-ci please test

@harlanhaskins
Copy link
Contributor Author

(I also want to make sure this doesn't introduce any new warnings)

@swift-ci please test source compatibility

@swift-ci
Copy link
Contributor

swift-ci commented Oct 5, 2018

Build failed
Swift Test OS X Platform
Git Sha - f94910babf6ca3afc78e9bd11d14a6247a8442f2

@swift-ci
Copy link
Contributor

swift-ci commented Oct 5, 2018

Build failed
Swift Test Linux Platform
Git Sha - f94910babf6ca3afc78e9bd11d14a6247a8442f2

@harlanhaskins
Copy link
Contributor Author

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).

/Users/buildnode/jenkins/workspace-private/swift-PR-source-compat-suite-debug/project_cache/ReactiveSwift/Sources/ValidatingProperty.swift:193:21: warning: all paths through this function will call itself
    public convenience init<U, E>(

And I think this is another false positive related to dynamic dispatch, similar to SR-7925

@harlanhaskins
Copy link
Contributor Author

Release source compat run failed while cloning Vapor, but I'm satisfied with the results from the debug run. @gottesmm Good to merge?

@gottesmm
Copy link
Contributor

gottesmm commented Oct 6, 2018

Let err rip.

@graydon
Copy link
Contributor

graydon commented Oct 8, 2018

This is causing failures. See rdar://45080912. Backing out.

graydon added a commit that referenced this pull request Oct 8, 2018
…terminates (#19724)"

This reverts commit e94450e.

rdar://45080912
modelorganism pushed a commit to modelorganism/swift that referenced this pull request Oct 11, 2018
…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.
modelorganism pushed a commit to modelorganism/swift that referenced this pull request Oct 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants