Skip to content
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

Properly mark ModuleOwnership as Sendable #109

Merged
merged 4 commits into from
Jul 16, 2024
Merged

Conversation

Supereg
Copy link
Member

@Supereg Supereg commented Jul 14, 2024

Properly mark ModuleOwnership as Sendable

♻️ Current situation & Problem

This PR adds a missing and forgotten Sendable conformance.

⚙️ Release Notes

  • Sendable and Hashable conformance for ModuleOwnership.

📚 Documentation

✅ Testing

📝 Code of Conduct & Contributing Guidelines

By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

@Supereg Supereg requested a review from PSchmiedmayer July 14, 2024 16:11
@Supereg Supereg force-pushed the fix/ownership-sendable branch from 6a153f9 to 5e22e62 Compare July 14, 2024 16:13
@Supereg
Copy link
Member Author

Supereg commented Jul 15, 2024

@PSchmiedmayer we have some XCTRuntimePreconditions that are impossible to test anymore with property data isolation (e.g., checking that a constraint is satisfied). With the recent change to XCTRuntimeAssertions (StanfordBDHG/XCTRuntimeAssertions#14), the closures passed to XCTRuntimePrecondition are now properly annotated as @Sendable closures. This makes it impossible to run XCTRuntimePreconditions with symbols that need to be isolated to the @MainActor. Either the closure will only run after the call to XCTRuntimePreconditions completed (if the call is made from the MainActor) or the MainActor will be blocked forever as the injected precondition(...) call loops forever.

Potential ways out:

  • Remove the @Sendable annotation from XCTRuntimePrecondition calls and just silently break concurrence guarantees.
  • Don't test preconditions anymore that are isolated to the MainActor.

What do you think is a sensible way going forward?

@PSchmiedmayer
Copy link
Member

@Supereg As discussed on Slack I would aim for a testing-specific but documented slightly unsafe behavior in XCTRuntimePrecondition to ensure that we can at least validate some assertions/preconditions within our codebases.

Copy link
Member

@PSchmiedmayer PSchmiedmayer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to see this merged once we addressed the current testing issues 🚀

@PSchmiedmayer PSchmiedmayer added the enhancement New feature or request label Jul 15, 2024
Copy link

codecov bot commented Jul 16, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 85.85%. Comparing base (fffb691) to head (d7ad126).

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff           @@
##             main     #109   +/-   ##
=======================================
  Coverage   85.85%   85.85%           
=======================================
  Files          45       45           
  Lines        1392     1392           
=======================================
  Hits         1195     1195           
  Misses        197      197           

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fffb691...d7ad126. Read the comment docs.

@Supereg Supereg merged commit afdf500 into main Jul 16, 2024
15 checks passed
@Supereg Supereg deleted the fix/ownership-sendable branch July 16, 2024 07:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

2 participants