Front-end: disable interface file locking for the -compile-module-from-interface action #32681
Conversation
…m-interface action The situations where we use this action, e.g. explicit module building and generating prebuilt module cache, don't need synchronization. We should avoid using lock files for them. rdar://65005528
|
@swift-ci please smoke test |
| if (Opts.RequestedAction == FrontendOptions::ActionType::CompileModuleFromInterface) { | ||
| // The situations where we use this action, e.g. explicit module building and | ||
| // generating prebuilt module cache, don't need synchronization. We should avoid | ||
| // using lock files for them. |
There was a problem hiding this comment.
What is the action for lazy module interface builds? It would be the only case where we would need the lock, is this right?
There was a problem hiding this comment.
That's correct. We only need lock file for regular compilation modes like -emit-module and -merge-modules because several compiler processes may attempt to build the same module.
There was a problem hiding this comment.
Aren't the sub invocations of the compiler for lazy module interface builds using the same -compile-module-from-interface flag? I'm worried this is disabling the lock even in other modes.
There was a problem hiding this comment.
Lazy module interface builds won't spawn a new front-end job to compile module from an interface file. Instead, the module building step happens implicitly in the main compilation action like -emit-module. We are moving towards explicitly module building where -compile-module-from-interface flag will be used, but that's where the lock file isn't necessary because all actions are performed synchronously.
There was a problem hiding this comment.
Alright, thanks for the explanation!
The situations where we use this action, e.g. explicit module building and
generating prebuilt module cache, don't need synchronization. We should avoid
using lock files for them.
rdar://65005528