[Dependency Scanning][C++Interop] Do not query CxxStdlib Swift overlay for textual modules which were not built with c++interop
#81415
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
artemcm
requested review from
cachemeifyoucan,
hborla,
slavapestov and
xedin
as code owners
|
@swift-ci test |
…lay for textual modules which were not built with c++interop When we discover a textual module dependency which is a module which was not originally built from source using C++ interop (specifying '-formal-cxx-interoperability-mode=off'), avoid looking up the C++ standard library Swift overlay for it. This is required for the case of the 'Darwin' module, for example, which includes headers which map to C++ stdlib headers when the compiler is operating in C++ interop mode, but the C++ standard library Swift overlay module itself depends on 'Darwin', which results in a cycle. To resolve such situations, we can rely on the fact that Swift textual interfaces of modules which were not built with C++ interop must be able to build without importing the C++ standard library Swift overlay, so we avoid specifying it as a dependency for such modules. The primary source module, as well as Swift textual module dependencies which *were* built with C++ interop will continue getting a direct depedency of the 'CxxStdlib' Swift module. Resolves rdar://150222155
artemcm
force-pushed
the
CXXInteropDarwinCycleFix
branch
from
afa70fb to
94898aa
Compare
|
@swift-ci test |
j-hui
reviewed
May 9, 2025
|
|
||
| // If the textual interface was built without C++ interop, do not query | ||
| // the C++ Standard Library Swift overlay for its compilation. | ||
| if (llvm::find(commandLine, "-formal-cxx-interoperability-mode=off") == |
There was a problem hiding this comment.
Is the reason we do a textual search here because we haven't loaded the module yet?
There was a problem hiding this comment.
Yes. The dependency scanner doesn't actually load modules. If/Once it finds a textual interface for a module dependency, we create a sub-instance to parse the module for its imports and compute a command-line recipe to build it, storing it in the ModuleInfo in the scanner. The build system client then uses this information to actually build this module for ingestion into compilation.
Because the module doesn't actually get loaded, we currently can only get this information from the command line. It would be reasonable to record this as a boolean flag in the ModuleInfo when we create one for this module, but I wanted to have a narrow fix first.
egorzhdan
approved these changes
May 12, 2025
hamishknight
added a commit
to hamishknight/swift
that referenced
this pull request
May 22, 2025
…winCycleFix" This reverts commit d1adc24.
artemcm
added a commit
to artemcm/swift
that referenced
this pull request
May 29, 2025
…tual modules which were not built with c++interop When the compiler is building a module without a defined formal C++ interop mode (e.g. building a textual interface which specifies it was built without C++ interop enabled), avoid looking up the C++ standard library Swift overlay for it. This is required for the case of the Darwin module, for example, which includes headers which map to C++ stdlib headers when the compiler is operating in C++ interop mode, but the C++ standard library Swift overlay module itself depends on 'Darwin', which results in a cycle. To resolve such situations, we can rely on the fact that Swift textual interfaces of modules which were not built with C++ interop must be able to build without importing the C++ standard library Swift overlay, so we avoid specifying it as a dependency for such modules. The primary source module, as well as Swift textual module dependencies which were built with C++ interop will continue getting a direct depedency of the 'CxxStdlib' Swift module. This was previously fixed in the dependency scanner for explicitly-built modules in swiftlang#81415.
artemcm
added a commit
to artemcm/swift
that referenced
this pull request
Jun 2, 2025
…tual modules which were not built with c++interop When the compiler is building a module without a defined formal C++ interop mode (e.g. building a textual interface which specifies it was built without C++ interop enabled), avoid looking up the C++ standard library Swift overlay for it. This is required for the case of the Darwin module, for example, which includes headers which map to C++ stdlib headers when the compiler is operating in C++ interop mode, but the C++ standard library Swift overlay module itself depends on 'Darwin', which results in a cycle. To resolve such situations, we can rely on the fact that Swift textual interfaces of modules which were not built with C++ interop must be able to build without importing the C++ standard library Swift overlay, so we avoid specifying it as a dependency for such modules. The primary source module, as well as Swift textual module dependencies which were built with C++ interop will continue getting a direct depedency of the 'CxxStdlib' Swift module. This was previously fixed in the dependency scanner for explicitly-built modules in swiftlang#81415.
artemcm
added a commit
to artemcm/swift
that referenced
this pull request
Jun 2, 2025
…tual modules which were not built with c++interop When the compiler is building a module without a defined formal C++ interop mode (e.g. building a textual interface which specifies it was built without C++ interop enabled), avoid looking up the C++ standard library Swift overlay for it. This is required for the case of the Darwin module, for example, which includes headers which map to C++ stdlib headers when the compiler is operating in C++ interop mode, but the C++ standard library Swift overlay module itself depends on 'Darwin', which results in a cycle. To resolve such situations, we can rely on the fact that Swift textual interfaces of modules which were not built with C++ interop must be able to build without importing the C++ standard library Swift overlay, so we avoid specifying it as a dependency for such modules. The primary source module, as well as Swift textual module dependencies which were built with C++ interop will continue getting a direct depedency of the 'CxxStdlib' Swift module. This was previously fixed in the dependency scanner for explicitly-built modules in swiftlang#81415.
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.
When we discover a textual module dependency which is a module which was not originally built from source using C++ interop (specifying '-formal-cxx-interoperability-mode=off'), avoid looking up the C++ standard library Swift overlay for it. This is required for the case of the 'Darwin' module, for example, which includes headers which map to C++ stdlib headers when the compiler is operating in C++ interop mode, but the C++ standard library Swift overlay module itself depends on 'Darwin', which results in a cycle. To resolve such situations, we can rely on the fact that Swift textual interfaces of modules which were not built with C++ interop must be able to build without importing the C++ standard library Swift overlay, so we avoid specifying it as a dependency for such modules.
The primary source module, as well as Swift textual module dependencies which were built with C++ interop will continue getting a direct depedency of the 'CxxStdlib' Swift module.
Resolves rdar://150222155