Do not schedule a syntactic test rescan if we know that we already have an up-to-date syntactic test index for it

If the build system is sending us with `buildTarget/didChange`, we would always create processor count * 4 new entries in the `indexingQueue` to rescan those files, if they are up-to-date. This can be quite wasteful if the underlying files didn’t actually change. Do a quick scan up-front to check if the files actually need to be re-scanned up-front.

Author: ahoppen

Sources/SourceKitLSP/Swift/SyntacticTestIndex.swift

@@ -151,12 +151,36 @@ actor SyntacticTestIndex {
 
   /// Called when a list of files was updated. Re-scans those files
   private func rescanFiles(_ uris: [DocumentURI]) {
-    logger.info("Syntactically scanning files for tests: \(uris)")
-
     // If we scan a file again, it might have been added after being removed before. Remove it from the list of removed
     // files.
     removedFiles.subtract(uris)
 
+    // If we already know that the file has an up-to-date index, avoid re-scheduling it to be indexed. This ensures
+    // that we don't bloat `indexingQueue` if the build system is sending us repeated `buildTarget/didChange`
+    // notifications.
+    // This check does not need to be perfect and there might be an in-progress index operation that is about to index
+    // the file. In that case we still schedule anothe rescan of that file and notice in `rescanFilesAssumingOnQueue`
+    // that the index is already up-to-date, which makes the rescan a no-op.
+    let uris = uris.filter { uri in
+      if let url = uri.fileURL,
+        let indexModificationDate = self.indexedTests[uri]?.sourceFileModificationDate,
+        let fileModificationDate = try? FileManager.default.attributesOfItem(atPath: url.filePath)[.modificationDate]
+          as? Date,
+        indexModificationDate >= fileModificationDate
+      {
+        return false
+      }
+      return true
+    }
+
+    guard !uris.isEmpty else {
+      return
+    }
+
+    logger.info(
+      "Syntactically scanning \(uris.count) files for tests: \(uris.map(\.arbitrarySchemeURL.lastPathComponent).joined(separator: ", "))"
+    )
+
     // Divide the files into multiple batches. This is more efficient than spawning a new task for every file, mostly
     // because it keeps the number of pending items in `indexingQueue` low and adding a new task to `indexingQueue` is
     // in O(number of pending tasks), since we need to scan for dependency edges to add, which would make scanning files