-
Notifications
You must be signed in to change notification settings - Fork 10.6k
[Explicit Module Builds] Restore prior behavior of consuming .h dependencies of binary module dependencies directly, instead of attempting to load their PCH
#69109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
632138a to
3e9bfc6
Compare
|
@swift-ci smoke test |
cachemeifyoucan
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some small comments. The change LGTM.
lib/Serialization/Serialization.cpp
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have test coverage for this? That is what happens when -disable-bridging-pch is used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
header_deps_of_binary.swift is testing this very thing. A binary module is being built with a direct .pch file and what is serialized in it is a .h of the source.
-disable-bridging-pch is a driver flag to always feed the .h directly to the TU compilation, instead of ever creating a PCH.
3e9bfc6 to
48e5d4d
Compare
|
@swift-ci test |
Hmm. |
48e5d4d to
9fa8f5a
Compare
|
@swift-ci test and merge |
…idging header is provided In explicit module builds, bridging header is passed directly as a '.pch' input. Loading clients may not be able to directly import this PCH because it was built against mis-matched dependencies with a different context hash. So instead they should directly injest the '.h' depndency and build it against their own set of dependencies.
9fa8f5a to
d2ad931
Compare
|
@swift-ci smoke test and merge |
…ng dependency PCH As of swiftlang/swift#69109 we no longer propagate the PCH to dependencies in non-cached builds. For cached builds, this functionality is tested in 'testCacheBuildEndToEndWithBinaryHeaderDeps'.
…ng dependency PCH As of swiftlang/swift#69109 we no longer propagate the PCH to dependencies in non-cached builds. For cached builds, this functionality is tested in 'testCacheBuildEndToEndWithBinaryHeaderDeps'.
…f binary modules unless in CAS mode We only record these dependencies in CAS mode, because we require explicit PCH tasks to be produced for imported header of binary module dependencies. In the meantime, in non-CAS mode loading clients will consume the `.h` files encoded in the `.swiftmodules` directly. Followup changes to SwiftDriver will enable explicit PCH compilation of such dependenceis, but for the time being restore prior behavior for non-CAS explicit module builds. Resolves rdar://116006619
d2ad931 to
75ee48c
Compare
…ng dependency PCH As of swiftlang/swift#69109 we no longer propagate the PCH to dependencies in non-cached builds. For cached builds, this functionality is tested in 'testCacheBuildEndToEndWithBinaryHeaderDeps'.
…ng dependency PCH As of swiftlang/swift#69109 we no longer propagate the PCH to dependencies in non-cached builds. For cached builds, this functionality is tested in 'testCacheBuildEndToEndWithBinaryHeaderDeps'.
.hpath when an explicit.pchbridging header is provided. In explicit module builds, bridging header is passed directly as a.pchinput. Loading clients may not be able to directly import this PCH because it was built against mis-matched dependencies with a different context hash. So instead they should directly ingest the.hdependency and build it against their own set of dependencies..hfiles encoded in the.swiftmodulesdirectly. Followup changes to SwiftDriver will enable explicit PCH compilation of such dependencies, but for the time being restore prior behavior for non-CAS explicit module builds.Resolves rdar://116006619