Skip to content

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

Merged
merged 1 commit into from
Jul 19, 2024

Conversation

grynspan
Copy link
Contributor

@grynspan grynspan commented Jul 19, 2024

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:

  • Code and documentation should follow the style of the Style Guide.
  • If public symbols are renamed or modified, DocC references should be updated.

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.)
@grynspan grynspan added enhancement New feature or request tools integration 🛠️ Integration of swift-testing into tools/IDEs performance 🏎️ Performance issues labels Jul 19, 2024
@grynspan grynspan self-assigned this Jul 19, 2024
@grynspan
Copy link
Contributor Author

@stmontgomery What do you think? This eliminates the need to capture a value inout or call a second-order function. Also now we can unit test it (not a particularly interesting test, but code coverage intensifies.)

@grynspan
Copy link
Contributor Author

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

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)

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

@grynspan grynspan merged commit f0730c4 into main Jul 19, 2024
3 checks passed
@grynspan grynspan deleted the jgrynspan/simplify-failure-breakpoint branch July 19, 2024 17:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request performance 🏎️ Performance issues tools integration 🛠️ Integration of swift-testing into tools/IDEs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants