Skip to content

Front-end: disable interface file locking for the -compile-module-from-interface action #32681

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

Merged
merged 1 commit into from
Jul 2, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 9 additions & 2 deletions lib/Frontend/ArgsToFrontendOptionsConverter.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -102,8 +102,6 @@ bool ArgsToFrontendOptionsConverter::convert(
Opts.RemarkOnRebuildFromModuleInterface |=
Args.hasArg(OPT_Rmodule_interface_rebuild);

Opts.DisableInterfaceFileLock |= Args.hasArg(OPT_disable_interface_lockfile);

computePrintStatsOptions();
computeDebugTimeOptions();
computeTBDOptions();
Expand Down Expand Up @@ -149,6 +147,15 @@ bool ArgsToFrontendOptionsConverter::convert(
Opts.RequestedAction = determineRequestedAction(Args);
}

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the action for lazy module interface builds? It would be the only case where we would need the lock, is this right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, thanks for the explanation!

Opts.DisableInterfaceFileLock = true;
} else {
Opts.DisableInterfaceFileLock |= Args.hasArg(OPT_disable_interface_lockfile);
}

if (Opts.RequestedAction == FrontendOptions::ActionType::Immediate &&
Opts.InputsAndOutputs.hasPrimaryInputs()) {
Diags.diagnose(SourceLoc(), diag::error_immediate_mode_primary_file);
Expand Down