We were checking the parent invocation's DiagnosticEnginer rather than the
subinstance's to determine if there were any errors building the module, which
meant we would fail to load the module if there were errors prior to the import
statement in the importing file.
This also meant code completion would fail to load the module, because it always
emits a bogus error in order to mark the AST as erroneous so that different
parts of the compiler (e.g. the verifier) have less strict assumptions.
rdar://problem/43906499
We were checking the parent invocation's DiagnosticEnginer rather than the
subinstance's to determine if there were any errors building the module, which
meant we would fail to load the module if there were errors prior to the import
statement in the importing file.
This also meant code completion would fail to load the module, because it always
emits a bogus error in order to mark the AST as erroneous so that different
parts of the compiler (e.g. the verifier) have less strict assumptions.
rdar://problem/43906499
Previously, we included the PCH hash components in the cache key. While they didn’t do any harm, they didn’t contribute any unique information about the module in question.
Additionally, passing the effective language version in means that each dependency that uses a different -swift-version would re-compile all of its dependencies. This is unfortunate, as that means the standard library is recompiled potentially several times.
Hashing the contents of the interface files is overkill. In practice, size and last modification time are enough to determine if a file has changed on disk, and therefore should be rebuilt.
If the frontend is invoked with
-build-module-from-parseable-interface, we might be trying to persist
and distribute the swiftmodule that gets built. In that case, any
dependencies we list might not be relevant.
This probably isn't really the final answer here; what we want is some
way to say /which/ dependencies are relevant, and how they're related
to how the swiftmodule that gets used. Most likely the right answer
here is to limit this to dependencies within the SDK or something.
Otherwise, the top-level compilation gets the benefit of the prebuilt
cache path, but the sub-invocations for swiftinterfaces that /do/
need to be compiled do not.
This is a little trickier than it sounds because we have 'friend'
access into the FrontendInputsAndOutputs structure, which means all
the helpers need to be declared in the header file. But it makes the
two use sites simpler, and does slightly less work in the cache hit
path.
The previous 'openModuleFiles' interface in SerializedModuleLoaderBase
still assumed that swiftmodule files and swiftdoc files would be found
next to each other, but that's not true anymore with
swiftinterfaces-built-to-modules. Give up on this assumption (and on
the minor optimization of passing down a scratch buffer) and split out
the interface into the customization point
'findModuleFilesInDirectory' and the implementation 'openModuleFiles'.
The latter now takes two full paths: one for the swiftmodule, one for
the swiftdoc.
Makes it easier to test the caching behavior, and may also be useful
for "prebuilding" swiftinterfaces in the future, or having the Driver
kick off a bunch of separate builds as proper tasks.
The goal here is to separate the parts that compute an output file
name from the parts that do the actual compilation, so that we can
test the swiftinterface -> swiftmodule behavior more directly. No
functionality change in this commit; the next will take advantage
of the refactoring.
Deinitializers are always @objc. (Arguably, this makes it unnecessary
to print, but we don't want to do any @objc inference at all in a
swiftinterface.)
- Use the name for the cached module, so that we don't end up with a
zillion "x86_64-XXXXXXXX.swiftmodule" files in the cache when we're
working with architecture-specific swiftmodules.
- Diagnose if the expected name is different from the name specified
in the swiftinterface.
- Emit all diagnostics at the location of the import, instead of
without any location at all.
This would break resilience, which makes a distinction between "SIL
only inside the module, which is inside the resilience domain" and
"SIL we're going to serialize, which is outside the resilience
domain".
Otherwise we've got a problem with modules that use -parse-stdlib but
aren't the stdlib themselves. Ideally we'd /only/ print this in that
case, but we don't have that information at this point in the pipeline
and I'm not sure it would be a good idea to include it in the set of
options we pass through.
