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.
Two places in Driver are creating temporary files at a point in the
process where failure is not expected. We should do something better
about this, but meanwhile harmonize their failures and include a
little more info.
Filed https://bugs.swift.org/browse/SR-11541 to improve this.
Windows requires a handle to get memory usage, so do a slight refactor
to collect the child's memory usage as it exits instead of as the parent
is cleaning up.
Shuffle the responsibility for creating the TaskQueue out of the
Compilation's internal job state object and into the driver. Expose
a builder convenience function that handles the argument parsing.
When providing the -parseable-output flag to the swift compiler, it will provide json formatted messages about tasks that run.
I added some optional usage information in form of user time, system time and maxrss to the output. This can be used by other tools using the compiler to get some insights about time and memory usage.
Since the output does not longer match processes run (in batch mode), I also added a real_pid field so the client could reason about jobs that belong together if needed.
rdar://39798231
The logic in 46b8ad3 to avoid putting certain diagnostics into
serialized diagnostic files only makes sense if
1. every diagnostic emitted in file A.swift while processing a
different file B.swift would be emitted if we processed A.swift on
its own
2. we actually do process A.swift on its own in the same build,
or have previously done an incremental build and produced the same
diagnostic
But the latter isn't actually guaranteed: if one batch job exits with
a failure status, the driver will exit as well, assuming there's no
point in continuing. Fortunately, we do have a flag that overrides
this behavior, -continue-building-after-errors.
(As noted in the patch, -continue-building-after-errors isn't *exactly*
what we want. But it's conservatively correct.)
