-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[ownership] When computing usesNotContainedWithinLifetime make sure the error is only a use not in lifetime error. #33618
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
[ownership] When computing usesNotContainedWithinLifetime make sure the error is only a use not in lifetime error. #33618
Conversation
…he error is only a use not in lifetime error. Otherwise, we can return true in cases where we do not have a proper linear lifetime which can occur in the presence of destructures. <rdar://problem/67698939>
// Return true if we /did/ found an error and when emitting that error, we | ||
// If we found any error except for uses outside of our lifetime, bail. | ||
if (error.getFoundLeak() || error.getFoundOverConsume() || | ||
error.getFoundUseAfterFree()) |
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.
Eventually I may want to have some sort of enum here. Makes me nervous doing these sorts of exhaustive checks. But this code doesn't change too much so I think it is ok for now.
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.
FWIW, I find it easier to think about APIs that don't involve double-negative. i.e. is should be '!usesContainded', not 'usesNotContained'
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.
Ok. I am fine with changing that.
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 am going to invert that in a follow on commit.
@swift-ci test |
@swift-ci test source compatibility |
@swift-ci benchmark |
Performance: -O
Code size: -OPerformance: -OsizeCode size: -OsizePerformance: -Onone
Code size: -swiftlibsHow to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
Otherwise, we can return true in cases where we do not have a proper linear
lifetime which can occur in the presence of destructures.
rdar://problem/67698939