Backport build and Windows fixes for 5.9 #794
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
Avoid polluting the build directory a small amount given that we can use `-fmodule-map-file=` for the C/C++ build of libdispatch. Unfortunately, for the Swift build, we need to have the file copied over due to the umbrella header resolution. Hopefully this reduces some of the race conditions that we have seen in the build. Thanks to @dgregor for reminding me of the flag!
Use a VFS overlay to avoid polluting the source tree.
There is a subtle difference between libdispatch built dynamically and statically: DispatchStubs. We erroneously emit ObjC runtime calls into the build and the stubs provides a shim to provide a definition on non-ObjC runtime enabled targets. When built dynamically, this is internalised and distributed as part of dispatch.dll/libdispatch.so, however when built statically, the consumer is responsible for linking against DispatchStubs. The modulemap reflects this and we need to ensure that we correctly provide that modulemap. Thanks to @MaxDesiatov for the help with debugging and testing a fix for this! Fixes: rdar://23335318
The `WaitChain*` functions require linking against AdvAPI32.
This function is the initializer for the semaphore. The seamphore storage itself may be stack allocated (or heap allocated) but without guarantee of 0-initialisation. As a result, the subsequent CAS for the atomic replacement will fail silently, leaving the previously non-zero value in place, indicating that the value is a valid handle. This would fail randomly and would ultimately result in a crash in the `CloseHandle` call associated with the clean up. This issue was identified by SwiftLint on Windows.
|
@swift-ci please test |
|
CC: @bnbarham |
etcwilde
approved these changes
Jun 6, 2023
There was a problem hiding this comment.
Looks good to me.
Cherry-Picks:
- Fix build break due to calling convention mismatch on Windows #784 (Windows fix)
- build: slightly improve the build for libdispatch #785 (module map overlay fix)
- build: add a link against AdvAPI32 on Windows #790 (Windows fix)
- shims: fix a subtle bug in semaphore initialisation on Windows #791 (Windows fix)
- dispatch: install the correct modulemap when building static #793 (module map overlay fix)
Explanation: Prevents the dispatch build from copying generated files into the source directory during the build. The copying results in an occasional race in CI, causing a spurious failure. Also fixed a calling-convention mismatch on Windows.
Risk: The risk to Darwin platforms is effectively nothing since this repository is not built for or shipped on Darwin.
Reviewed By: @etcwilde @MaxDesiatov @compnerd @tristanlabelle @bnbarham
|
Please test with following PRs: @swift-ci please test |
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.
Backport a number of changes from main to the 5.9 release