It is a maintenance burden and having the legacy driver exist in a simplified state reduces the possibility of things going wrong and hitting old bugs.
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.)
The driver exits out early if there's no stdlib for the target you're
compiling for, and these tests didn't pass a target for one reason or
another.
rdar://problem/29173390
Currently the Swift driver stops invoking frontend commands as soon as one of
them reports an error. Add a flag to control this behavior, so that users can
choose whether to see all the errors at once or bail out early.
