-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Runtime] Fix leak when casting to AnyHashable. #20836
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
_dynamicCastToAnyHashable assumed that _swift_convertToAnyHashableIndirect takes its argument at +1, but that is no longer the case. rdar://problem/44686587
@swift-ci please test |
do { | ||
let tracked = LifetimeTracked(42) | ||
let anyHashable = AnyHashable(tracked) | ||
let anyObject = anyHashable as AnyObject |
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.
This is testing two different cases. Aren't there 3 types of cast consumption? I think you will need a full on address only type to test that, no? Maybe my memory is wrong.
Build failed |
sourceType->deallocateBufferIn(&buffer); | ||
// Destroy the value if requested. | ||
if (flags & DynamicCastFlags::TakeOnSuccess) { | ||
sourceType->vw_destroy(source); |
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.
The other way of doing this, by the way, would be to mark the intrinsic parameter as __owned
. I don't have an opinion about whether TakeOnSuccess
or !TakeOnSuccess
is more important to optimize.
The call to swift_unboxFromSwiftValueWithType needs to destroy the value on success when requested in the flags. rdar://problem/44686587
@swift-ci please test |
Build failed |
Build failed |
_dynamicCastToAnyHashable
assumed that_swift_convertToAnyHashableIndirect
takes its argument at +1, but that is no longer the case.rdar://problem/44686587