[Test] Make implicit_weak_capture.swift more robust. #81957
Conversation
This test creates an object then checks a weak reference to that object on a background thread. It was doing this check after 10ms, and any small hiccup could potentially delay the object's destruction enough to spuriously fail. Rearrange the test to check the weak reference in a loop for several seconds before giving up. This makes it very fast on success (it's done the moment it sees nil) while being robust against up to several seconds of delay in destroying the object if that happens. rdar://149868181
|
@swift-ci please test |
| fatalError("Self was unexpectedly captured strongly") | ||
|
|
||
| runIn10ms { [self] in | ||
| // Use implicit self -- this should not result in a strong capture |
There was a problem hiding this comment.
apologies for the drive-by commentary, but i find this comment (and surrounding logic) a bit confusing – if execution were to get to this point, wouldn't self already be strongly captured (by the earlier strong binding and capture list item)? what is this trying to test?
There was a problem hiding this comment.
I'm just adjusting the test to be more reliable, I'm not super familiar with it, but I believe the idea is to make sure the compiler generates code such that the nested closure doesn't capture self strongly. The execution path at runtime isn't too important, other than the fact that we want to detect that unwanted strong capture by getting to this point.
|
@swift-ci please test macos platform |
|
Looks like the macOS build just sort of stopped doing anything and eventually timed out. Weird. |
|
@swift-ci please test macos platform |
|
And again! It's not getting anywhere near running this test so it's not caused by my changes. Very strange. Retrying once more.... |
|
@swift-ci please test macos platform |
|
@swift-ci please test macOS platform |
This test creates an object then checks a weak reference to that object on a background thread. It was doing this check after 10ms, and any small hiccup could potentially delay the object's destruction enough to spuriously fail.
Rearrange the test to check the weak reference in a loop for several seconds before giving up. This makes it very fast on success (it's done the moment it sees nil) while being robust against up to several seconds of delay in destroying the object if that happens.
rdar://149868181