[Explicit Module Builds] Only specify '-fmodule-map-file' for bridging header Clang module dependencies #72668
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
…ule dependencies' header inputs' module dependencies
|
@swift-ci smoke test |
cachemeifyoucan
approved these changes
Mar 28, 2024
…g header Clang module dependencies Relying on the corresponding field in the '-explicit-swift-module-map-file' provided by the driver. Only bridging headers require a module map because that's what aids header include resolution. With lazy module loading today, '.modulemap' parsing which happens when instantiating Clang is responsible for associating headers with modules. Then upon encountering a header include inside the bridging header the compiler knows which module corresponds to said header and is then able to load explicitly-provided PCM for that module. For all other module dependencies, they are only ever queried by-name from Swift, so '.modulemap' parsing is not necessary.
artemcm
requested review from
ahoppen,
bnbarham,
hamishknight,
rintaro,
tshortli,
hborla,
slavapestov and
xedin
as code owners
artemcm
changed the title
|
@cachemeifyoucan sorry, I've expanded the scope of this PR, because I want these changes to land in-tandem on the compiler. Could you please take another look? |
|
@swift-ci test |
cachemeifyoucan
approved these changes
Mar 28, 2024
| @@ -476,7 +476,7 @@ class SearchPathOptions { | |||
| std::vector<std::string> CandidateCompiledModules; | |||
|
|
|||
| /// A map of explicit Swift module information. | |||
| std::string ExplicitSwiftModuleMap; | |||
| std::string ExplicitSwiftModuleMapPath; | |||
There was a problem hiding this comment.
The caching build doesn't really take a path here (but a CASID). Maybe it wasn't a good idea to reuse this flag for caching build for the first place.
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.
Relying on the corresponding field in the '-explicit-swift-module-map-file' provided by the driver.
Only bridging headers require a module map because that's what aids header include resolution. With lazy module loading today, '.modulemap' parsing which happens when instantiating Clang is responsible for associating headers with modules. Then upon encountering a header include inside the bridging header the compiler knows which module corresponds to said header and is then able to load explicitly-provided PCM for that module. For all other module dependencies, they are only ever queried by-name from Swift, so '.modulemap' parsing is not necessary.
[Dependency Scanning] Add libSwiftScan entrypoint to query binary module dependencies' header inputs' module dependencies