Very rarely the last stderr output from a plugin subprocess could get lost (#4236)

This could happen because the Process termination handler only called `availableData` and not `readToEnd()`, so based on timing, there might be data that had been emitted by the plugin subprocess before it exited but that hadn't yet been received.

This caused sporadic failures of the `testLocalAndRemoteToolDependencies` unit test.

The fix is to switch to using `readToEnd()`.  This was not a problem for messages from the plugin, because they were already being read (and not collected using `availableData`).

rdar://89490777

Author: abertelrud

Sources/Workspace/DefaultPluginScriptRunner.swift

@@ -446,14 +446,16 @@ public struct DefaultPluginScriptRunner: PluginScriptRunner, Cancellable {
         let stderrPipe = Pipe()
         let stderrLock = Lock()
         var stderrData = Data()
-        stderrPipe.fileHandleForReading.readabilityHandler = { fileHandle in
+        let stderrHandler = { (data: Data) in
             // Pass on any available data to the delegate.
-            stderrLock.withLock {
-                let data = fileHandle.availableData
-                if data.isEmpty { return }
-                stderrData.append(contentsOf: data)
-                callbackQueue.async { delegate.handleOutput(data: data) }
-            }
+            if data.isEmpty { return }
+            stderrData.append(contentsOf: data)
+            callbackQueue.async { delegate.handleOutput(data: data) }
+        }
+        stderrPipe.fileHandleForReading.readabilityHandler = { fileHandle in
+            // Read and pass on any available free-form text output from the plugin.
+            // We need the lock since we could run concurrently with the termination handler.
+            stderrLock.withLock { stderrHandler(fileHandle.availableData) }
         }
         process.standardError = stderrPipe
 
@@ -473,7 +475,10 @@ public struct DefaultPluginScriptRunner: PluginScriptRunner, Cancellable {
             try? outputHandle.close()
 
             // Read and pass on any remaining free-form text output from the plugin.
-            stderrPipe.fileHandleForReading.readabilityHandler?(stderrPipe.fileHandleForReading)
+            // We need the lock since we could run concurrently with the readability handler.
+            stderrLock.withLock {
+                try? stderrPipe.fileHandleForReading.readToEnd().map{ stderrHandler($0) }
+            }
 
             // Read and pass on any remaining messages from the plugin.
             stdoutPipe.fileHandleForReading.readabilityHandler?(stdoutPipe.fileHandleForReading)