...a situation we get into with indexing. The way Xcode generates
indexing invocations is to take a build command and add additional
flags to it; in order for the Driver to produce a single frontend
command from /that/, it currently plans as if it's going to do a
whole-module -typecheck and then turns around and uses -primary-file
anyway. This is questionable practice, to be sure...
...but meanwhile, let's not crash by trying to access declarations
that haven't been type-checked yet.
rdar://problem/53117124
Instead of SILGen'ing all primary files before we go on to optimize
and IRGen them, run each file to completion before starting the next
one. This reduces memory usage.
I'm not sure why this wasn't already broken, but with the changes in
the next commit the multifile module trace test fails complaining that
it can't get a path for the main module. But we don't /need/ a path
for the main module because it's not a dependency of itself.
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances in the swift repo.
Pending: support for tracking depedencies through -import-underlying-module
and -import-objc-header.
Fixes rdar://problem/51825495 and rdar://problem/51825644.
It'll dump it for all the frontend jobs spawned from a driver, too,
but then the driver will buffer the response, so it's not that useful.
Requires LLVM r365911.
Apart from not having to write out the SDK path, this allows us to
properly distinguish system and non-system dependencies. (Well, as
properly as we were doing before this commit, i.e. whether something
comes from the SDK.)
Groundwork for rdar://problem/53279521
This mode is supposed to get all its configuration information from
the switftinterface being read in, but that means that the ASTContext
and ClangImporter that get created by default may not be a sensible
configuration (for example, a mismatched target and SDK, which Clang
emits a warning about). Avoid this by just not creating the ASTContext
if it's already been determined that the frontend is building a module
from a parseable interface.
These observer methods were used by external clients. Since we no longer
have the granularity between diagnostics and optimization, they're
rolled into a new observer callback, `performedSILProcessing`.
This (effectively) reverts commit 7b43e1d04d.
Previously, we wouldn't pass this flag to sub-invocations, which means
that if we had to fall back and recompile a transitive import, we
wouldn't get a remark.
rdar://50729662
Module interfaces don't yet carry enough information to correctly
describe the binary interface of a module compiled without
-enable-library-evolution, but we don't want to make this an error
because that would make it harder to work towards getting it in the
future.
If the project ever drops Swift 4 mode or Swift 4.2 mode, that would
break modules using those modes in their interface, so put an
unsilenceable warning in for using those modes to nudge interface
emitters to Swift 5.
rdar://problem/47792595
Sema no longer adds conformances to a per-SourceFile list that it thinks
are going to be "used" by SILGen, IRGen and the runtime. Instead, previous
commits already ensure that SILGen determines the set of conformances to be
emitted, triggering conformance checking as needed.
Leave the old flag in as an alias to the new flag, for transition
purposes. Also go ahead and remove the long-deprecated and unused
`emit-interface-path`.
Part of rdar://49359734
Updates the subinvocation that builds the parseable interface to respect the
-track-system-dependencies flag of the top-level invocation if present, by
including system dependencies in the produced .swiftmodule.
