[Driver] -enable-batch-mode implies -continue-building-after-errors

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.)

Author: jrose-apple

lib/Driver/Compilation.cpp

@@ -528,6 +528,11 @@ namespace driver {
                               ReturnCode);
         }
 
+        // See how ContinueBuildingAfterErrors gets set up in Driver.cpp for
+        // more info.
+        assert((Comp.ContinueBuildingAfterErrors || !Comp.EnableBatchMode) &&
+               "batch mode diagnostics require ContinueBuildingAfterErrors");
+
         return Comp.ContinueBuildingAfterErrors ?
           TaskFinishedResponse::ContinueExecution :
           TaskFinishedResponse::StopExecution;

lib/Driver/Driver.cpp

@@ -667,8 +667,6 @@ Driver::buildCompilation(const ToolChain &TC,
   }
 
   bool SaveTemps = ArgList->hasArg(options::OPT_save_temps);
-  bool ContinueBuildingAfterErrors =
-    ArgList->hasArg(options::OPT_continue_building_after_errors);
   bool ShowDriverTimeCompilation =
     ArgList->hasArg(options::OPT_driver_time_compilation);
 
@@ -703,6 +701,21 @@ Driver::buildCompilation(const ToolChain &TC,
   OI.CompilerMode = computeCompilerMode(*TranslatedArgList, Inputs, BatchMode);
   buildOutputInfo(TC, *TranslatedArgList, BatchMode, Inputs, OI);
 
+  // Note: Batch mode handling of serialized diagnostics requires that all
+  // batches get to run, in order to make sure that all diagnostics emitted
+  // during the compilation end up in at least one serialized diagnostic file.
+  // Therefore, treat batch mode as implying -continue-building-after-errors.
+  // (This behavior could be limited to only when serialized diagnostics are
+  // being emitted, but this seems more consistent and less surprising for
+  // users.)
+  // FIXME: We don't really need (or want) a full ContinueBuildingAfterErrors.
+  // If we fail to precompile a bridging header, for example, there's no need
+  // to go on to compilation of source files, and if compilation of source files
+  // fails, we shouldn't try to link. Instead, we'd want to let all jobs finish
+  // but not schedule any new ones.
+  const bool ContinueBuildingAfterErrors =
+      BatchMode || ArgList->hasArg(options::OPT_continue_building_after_errors);
+
   if (Diags.hadAnyError())
     return nullptr;
 

test/Driver/continue-building-after-errors.swift

@@ -1,10 +1,16 @@
 // RUN: not %target-build-swift %S/Inputs/error.swift %s 2>&1 | %FileCheck %s
 // RUN: not %target-build-swift -continue-building-after-errors %S/Inputs/error.swift %s 2>&1 | %FileCheck -check-prefix=CHECK-CONTINUE %s
 
+// Check that batch mode implies -continue-building-after-errors.
+// RUN: touch %t.empty.swift
+// RUN: not %target-build-swift -enable-batch-mode -j2 %S/Inputs/error.swift %S/../Inputs/empty.swift %s %t.empty.swift 2>&1 | %FileCheck -check-prefix=CHECK-BATCH %s
+
 // CHECK: self.bar = self.bar
 // CHECK-NOT: self.baz = self.baz
 // CHECK-CONTINUE: self.bar = self.bar
 // CHECK-CONTINUE: self.baz = self.baz
+// CHECK-BATCH-DAG: self.bar = self.bar
+// CHECK-BATCH-DAG: self.baz = self.baz
 struct Bar {
   let baz: Int
   init() {