Frontend outputs source-as-compiled, and source-ranges file with function body ranges and ranges that were unparsed in secondaries.
Driver computes diffs for each source file. If diffs are in function bodies, only recompiles that one file. Else if diffs are in what another file did not parse, then the other file need not be rebuilt.
✔ More informative error messages in case of crashes.
✔ Handling and documenting different cases.
✔ Test cases for different cases.
✔ Make SDKDependencies.swift pass again.
...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.