This mechanism allows the compiler to use a backup interface file to build into a binary module when
a corresponding interface file from the SDK is failing for whatever reasons. This mechansim should be entirely opaque
to end users except several diagnostic messages communicating backup interfaces are used.
Part of rdar://77676064
-compile-module-from-interface action now takes arguments of -candidate-module-file.
If one of the candidate module files is up-to-date, the action emits a forwarding
module pointing to the candidate module instead of building a binary module.
Module interface builder used to maintain a separate compiler instance for
building Swift modules. The configuration of this compiler instance is also
useful for dependencies scanner because it needs to emit front-end compiler invocation
for building Swift modules explicitly.
This patch refactor the configuration out to a delegate class, and the
delegate class is also used by the dependency scanner.
Additional flags in interface files may change parsing behavior like #if
statements. We should use a fresh ASTContext with these additional
flags when parsing interface files to collect imports.
rdar://62612027
When a swiftinterface fails to build for any of various reasons, we try to diagnose the failure at the site of the `import` declaration. But if the import is implicitly added—which happens for many SDK modules, like the standard library and ClangImporter overlays—there is no source location for the import, so the error ends up being diagnosed at <unknown>:0. This causes a number of issues; most notably, Xcode doesn’t display the diagnostic as prominently as others.
This change falls back to diagnosing the error at line 1, column 1 of the swiftinterface file itself. This is perhaps not an ideal location, and it won’t help with I/O errors where we can’t open the swiftinterface file (and therefore can’t diagnose an error in it), but it should improve the way we display most module interface building errors.
Currently, when a swiftinterface file fails to load, we emit the specific diagnostics for the failures, followed by a generic “failed to load module ‘Foo’” message. This PR improves that final diagnostic, particularly when the cause may be that the interface was emitted by a newer compiler using backwards-incompatible syntax.
This ensures only one process is generating module cache from an interface
file so that we don't blow up memory usage when multiple processes are
doing the same. The locking mechanism is similar to that of Clang's.
A better approach is that the build system takes care of the module building
step as a formal dependency.
rdar://52839445
