[Dependency Scanning] Do not add cross-import overlays that involve the main module being scanned

For example, when scanning a source module `Foo`, which, when depending on module `Bar` causes a cross-import overlay `_Foo_Bar` to be added, do not add this cross-import overlay when scanning `Foo` itself. For example, if `Foo` adds a dependency on `Bar` itself in its own dependency graph.

Author: artemcm

lib/AST/ModuleLoader.cpp

@@ -211,8 +211,6 @@ ModuleDependencyInfo::collectCrossImportOverlayNames(ASTContext &ctx,
       break;
     }
     case swift::ModuleDependencyKind::SwiftSource: {
-      auto *swiftSourceDep = getAsSwiftSourceModule();
-      assert(!swiftSourceDep->sourceFiles.empty());
       return result;
     }
     case swift::ModuleDependencyKind::SwiftPlaceholder: {

lib/DependencyScan/ScanDependencies.cpp

@@ -405,6 +405,10 @@ static void discoverCrossImportOverlayDependencies(
   // Modules explicitly imported. Only these can be secondary module.
   llvm::SetVector<Identifier> newOverlays;
   for (auto dep : allDependencies) {
+    // Do not look for overlays of main module under scan
+    if (dep.first == mainModuleName)
+      continue;
+
     auto moduleName = dep.first;
     auto dependencies = cache.findDependency(moduleName, dep.second).value();
 
@@ -413,8 +417,12 @@ static void discoverCrossImportOverlayDependencies(
         instance.getASTContext(), moduleName);
     if (overlayMap.empty())
       continue;
+
     std::for_each(allDependencies.begin(), allDependencies.end(),
                   [&](ModuleDependencyID Id) {
+                    // Do not look for overlays of main module under scan
+                    if (Id.first == mainModuleName)
+                      return;
                     // check if any explicitly imported modules can serve as a
                     // secondary module, and add the overlay names to the
                     // dependencies list.

test/ScanDependencies/Inputs/CHeaders/ExtraCModules/SubE.h

@@ -0,0 +1 @@
+void funcEE(void);

test/ScanDependencies/Inputs/CHeaders/ExtraCModules/module.modulemap

@@ -0,0 +1,4 @@
+module SubE {
+  header "SubE.h"
+  export *
+}

test/ScanDependencies/no_main_module_cross_import.swift

@@ -0,0 +1,23 @@
+// RUN: %empty-directory(%t)
+// RUN: mkdir -p %t/clang-module-cache
+// RUN: %target-swift-frontend -scan-dependencies -module-cache-path %t/clang-module-cache %s -o %t/deps.json -I %S/Inputs/CHeaders -I %S/Inputs/CHeaders/ExtraCModules -I %S/Inputs/Swift -emit-dependencies -emit-dependencies-path %t/deps.d -swift-version 4 -module-name SubE
+// Check the contents of the JSON output
+// RUN: %FileCheck %s < %t/deps.json
+
+// REQUIRES: executable_test
+// REQUIRES: objc_interop
+
+// Ordinarily, importing `E` and `SubE` triggers a cross-import of `_cross_import_E`, but not here, because we are building `SubE` Swift module itself.
+import EWrapper
+import SubE
+
+// CHECK:  "directDependencies": [
+// CHECK-DAG:   "swift": "EWrapper"
+// CHECK-DAG:   "clang": "SubE"
+// CHECK-DAG:   "swift": "Swift"
+// CHECK-DAG:   "swift": "SwiftOnoneSupport"
+// CHECK-DAG:   "swift": "_Concurrency"
+// CHECK-DAG:   "swift": "_StringProcessing"
+// CHECK-DAG:   "clang": "_SwiftConcurrencyShims"
+
+// CHECK-NOT:   "swift": "_cross_import_E"