-
Notifications
You must be signed in to change notification settings - Fork 112
Simplify failureBreakpoint()
and add a unit test.
#557
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
This PR simplifies the "unique" action performed by `failureBreakpoint()` to avoid de-duplication and implements a unit test to confirm that action is actually occurring and not being optimized away (at least under the current compiler settings at the time of test.)
@stmontgomery What do you think? This eliminates the need to capture a value |
@swift-ci please test |
NoOp.perform(&NoOp.ignored) | ||
// operation on a usable-from-inline value, which the compiler must assume | ||
// cannot be optimized away. | ||
failureBreakpointValue = 1 |
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 we were to enable the Thread Sanitizer and run our test suite, would it flag this as a data race? (Despite always assigning the same value)
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.
Nope, but if it did I would expect the original implementation would have the same issue.
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'd be surprised if both of them did not report a TSan race. But you're saying you tried and they did not? 🤔
Either way, this PR seems fine. I just really want to avoid transforming this into a global incrementing counter in the future, since then it would require a lock and would increase the overhead of every test failure.
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 tried and didn't see any race reported even when I bombarded it with a whole bunch of concurrent detached tasks. So if TSan is watching that address, it needs more coffee.
But that all said, we can switch to an atomic store in the future if we did want a counter. No lock needed.
This PR simplifies the "unique" action performed by
failureBreakpoint()
to avoid de-duplication and implements a unit test to confirm that action is actually occurring and not being optimized away (at least under the current compiler settings at the time of test.)Checklist: