Fix Swift Compiler Modules support in Debug mode #73506
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
The new `swift-driver` seems to enqueue a `wrapmodule` job which uses the given `module-name` to form the output file name when not doing optmizations (seems to happen only for `-Onone` in my testing). Since the CMake functions macros are using the module name also as the explicit output name, this clashes and ends up in an unhelpful error message from the driver. ``` SwiftDriverExecution/MultiJobExecutor.swift:207: Fatal error: multiple producers for output ... SwiftCompilerSources/Basic.o: Wrapping Swift module Basic & Compiling Basic SourceLoc.swift ``` The changes use a different output object name (by using `.object.o` suffix) which does not clash with what the `swift-driver` does automatically. The code around the output objects and the static libraries have to change slightly to handle this case. Additionally, the resulting library when in `Debug` is now declaring its dependency on `swiftSwiftOnoneSupport`, to avoid linking errors when the libraries are used in the final binaries.
Debug mode seems to enable PURE_BRIDGING_MODE, which seems to skip transitively including some C headers that files like `Utilities/Test.swift` depend on. To avoid errors building, add the missing include in a new `#else` branch.
|
@swift-ci please test |
eeckstein
approved these changes
May 8, 2024
|
Failed because of swiftlang/llvm-project#8714 |
|
@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.
The new
swift-driverseems to enqueue awrapmodulejob which usesthe given
module-nameto form the output file name when not doingoptmizations (seems to happen only for
-Ononein my testing). Since theCMake functions macros are using the module name also as the explicit output
name, this clashes and ends up in an unhelpful error message from the driver.
This was reported in https://forums.swift.org/t/debug-swift-build-fails/71380
The changes use a different output object name (by using
.object.osuffix) which does not clash with what the
swift-driverdoesautomatically. The code around the output objects and the static
libraries have to change slightly to handle this case.
Additionally, the resulting library when in
Debugis now declaring itsdependency on
swiftSwiftOnoneSupport, to avoid linking errors when thelibraries are used in the final binaries.
Debug mode seems to enable PURE_BRIDGING_MODE, which seems to skip
transitively including some C headers that files like
Utilities/Test.swiftdepend on. To avoid errors building, add themissing include in a new
#elsebranch.I think CI will not test the
Debugmode, so the only thing that it can prove isthat these changes do not break the
Releasemode.