[Frontend] Emit incremental compilation info from some emit-module jobs #38211
Conversation
|
@swift-ci Please smoke test |
|
I'm mostly putting this PR up in support for testing swiftlang/swift-driver#730. @CodaFi Are there tests in the compiler repo that could be extended to test this or are they on the driver side? |
|
There are some tests under |
|
swiftlang/swift-driver#730 |
|
Build failed |
|
Build failed |
|
@swift-ci Please smoke test |
xymus
force-pushed
the
incr-info-and-emit-module
branch
from
63b283c to
7ec8c4e
Compare
|
@swift-ci Please smoke test |
lib/FrontendTool/FrontendTool.cpp
Outdated
| auto *Mod = MSF.get<ModuleDecl *>(); | ||
|
|
||
| StringRef fileFingerprint; | ||
| if (auto Mod = MSF.dyn_cast<ModuleDecl *>()) { |
There was a problem hiding this comment.
I'm a bit confused as to how we see SourceFiles here. There shouldn't be any primaries, so this path should only be fed by ModuleDecls, right?
There was a problem hiding this comment.
Emit module only has source file inputs that end up here. Do you think that shouldn't happen?
I wouldn't expect this job to be passed the primary flag but I could double check in the tests where this failed.
There was a problem hiding this comment.
My expectation is that separate module mode behaves like WMO, not like single-file mode. There shouldn't be primaries here.
There was a problem hiding this comment.
Good point! IIUC a jobs with the action -emit-module and using a primary-file would be used to create a partial swiftmodule file, so I'll modify this code to avoid jobs with a SourceFile and it should just generate the graph for module-wide emit-module jobs.
lib/Frontend/Frontend.cpp
Outdated
| @@ -343,7 +343,8 @@ void CompilerInstance::setupDependencyTrackerIfNeeded() { | |||
| // If we have an output path specified, but no other tracking options, | |||
| // default to non-system dependency tracking. | |||
| if (opts.InputsAndOutputs.hasDependencyTrackerPath() || | |||
| !opts.IndexStorePath.empty()) { | |||
| !opts.IndexStorePath.empty() || | |||
| opts.RequestedAction == FrontendOptions::ActionType::EmitModuleOnly) { | |||
There was a problem hiding this comment.
@CodaFi What do you think of forcing dependency tracking for all emit module only jobs? The data structure configured here is used later to generate the fine grained dependency graph which is also now built by default with all emit module only jobs.
There was a problem hiding this comment.
This part of the code is about forcing system (read: SDK) dependencies on and off when we import stuff via the clang importer. I don't think you need to amend this logic. The user should be the one in control here with -track-system-dependencies.
There was a problem hiding this comment.
This change is no more necessary when fixing the SourceFile issue above.
xymus
force-pushed
the
incr-info-and-emit-module
branch
from
7ec8c4e to
fd2bea0
Compare
|
@swift-ci Please smoke test |
|
swiftlang/swift-driver#730 |
xymus
force-pushed
the
incr-info-and-emit-module
branch
from
fd2bea0 to
26c44ef
Compare
|
@swift-ci Please smoke test |
Enable emitting the module-level incremental fine-grained compilation information from the emit-module job for incremental compilation to work with emit-module-separately.
The differentiation and actor logics insert SynthesizedFileUnit in SourceFile modules. Accepting these file units in populateMemberCache allow to cache all the top-level decls of source file modules.
xymus
force-pushed
the
incr-info-and-emit-module
branch
from
26c44ef to
6fd9102
Compare
|
@swift-ci Please smoke test |
xymus
changed the title
|
@swift-ci Please smoke test Linux |
|
@swift-ci Please smoke test Windows |
Emit the incremental fine-grained information from the emit-module job to improve the emit-module-separately build mode compatibility with incremental compilation. Note that emit-module doesn't usually parses or type-checks non-inlinable function bodies so it may be unaware of some dependencies.