[concurrency] Import module on OpenBSD if enabled. #37027
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Tests are written under the assumption that since they are conditioned on the concurrency feature, the explicit `_Concurrency` module import is not necessary since it is imported implicitly if concurrency is enabled. However, this is not the case; the module import is only included implictly on selected targets. It may very well be ideal to import the `_Concurrency` module implicitly when `SWIFT_ENABLE_EXPERIMENTAL_CONCURRENCY` is true and therefore solve the incorrect assumption, however, that decision is something that is above my pay grade. Some guidance on this is welcome. That being said, on OpenBSD, Dispatch is currently unsupported upstream but there is a draft PR to add this support (559). This means that even while we have draft Dispatch support, all the Concurrency tests fail because they do not import `_Concurrency`, but we cannot unconditionally support concurrency until Dispatch is supported upstream. Therefore, we especially need to support both cases. So instead, on OpenBSD, if the concurrency feature is enabled, import the module implicitly, otherwise, do not. This lets us run the tests and get a good signal that concurrency features are working with the draft Dispatch support, while avoiding problems when building with the documented configuration that disables Dispatch, and therefore, disables concurrency.
|
@swift-ci smoke test and merge |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Tests are written under the assumption that since they are conditioned
on the concurrency feature, the explicit
_Concurrencymodule import isnot necessary since it is imported implicitly if concurrency is enabled.
However, this is not the case; the module import is only included
implictly on selected targets.
It may very well be ideal to import the
_Concurrencymodule implicitlywhen
SWIFT_ENABLE_EXPERIMENTAL_CONCURRENCYis true and therefore solvethe incorrect assumption, however, that decision is something that is
above my pay grade. Some guidance on this is welcome.
That being said, on OpenBSD, Dispatch is currently unsupported upstream
but there is a draft PR to add this support (559). This means that even
while we have draft Dispatch support, all the Concurrency tests fail
because they do not import
_Concurrency, but we cannot unconditionallysupport concurrency until Dispatch is supported upstream.
Therefore, we especially need to support both cases. So instead, on
OpenBSD, if the concurrency feature is enabled, import the module
implicitly, otherwise, do not. This lets us run the tests and get a good
signal that concurrency features are working with the draft Dispatch
support, while avoiding problems when building with the documented
configuration that disables Dispatch, and therefore, disables
concurrency.