-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.
And also rename the underlying request and
descriptor.
This rename is motivated by the fact that the
operation may instead perform parsing of SIL files
and/or deserialization of SIB files.
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.
Because we block the calling thread, this should be safe for the existing
implementation of PrettyStackTrace; however, it would be much nicer if
LLVM provided direct support for this.
The most important thing from the trace that we want to print is the
original command line, so an alternative would be to just make a
PrettyStackTrace that printed all of the CompilerInvocation context;
I think that's accessible somewhere. But this is a nice, simple
improvement.
Remove the option to switch off nested types tables. In a world where
re-entrant direct lookup will cause deserialization to fail (or worse),
disabling these tables will only lead to further instability in the
compiler.
When a swift module is generated from a swift interface file, we must
remember to setup the nested types tables. Plumb the flag down from the
frontend options.
In the future, we must remove the ability to turn this off. There's
literally zero reason to have this be a configuration option anymore.
Resolves rdar://59202687 and its many, many dupes.
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
This change ensures using .swiftmodule built from source has the same behavior as
using .swiftmodule built from .swiftinterface.
A swift-ide-test utility is added to print linked libraries from a Swift module for
testing purposes.
rdar://58057556
