Merge pull request #32432 from xymus/module-loading-order-5.3

[5.3][ModuleInterface] Prefer the swiftmodule in the SDK over the prebuilt-module cache

Author: tkremenek

lib/Frontend/ModuleInterfaceLoader.cpp

@@ -738,8 +738,52 @@ class ModuleInterfaceLoaderImpl {
       }
     }
 
-    // If we weren't able to open the file for any reason, including it not
-    // existing, keep going.
+    // [Note: ModuleInterfaceLoader-defer-to-SerializedModuleLoader]
+    // If there's a module adjacent to the .swiftinterface that we can
+    // _likely_ load (it validates OK and is up to date), bail early with
+    // errc::not_supported, so the next (serialized) loader in the chain will
+    // load it.
+    // Alternately, if there's a .swiftmodule present but we can't even
+    // read it (for whatever reason), we should let the other module loader
+    // diagnose it.
+
+    if (shouldLoadAdjacentModule) {
+      auto adjacentModuleBuffer = fs.getBufferForFile(modulePath);
+      if (adjacentModuleBuffer) {
+        if (serializedASTBufferIsUpToDate(modulePath, *adjacentModuleBuffer.get(),
+                                          deps)) {
+          LLVM_DEBUG(llvm::dbgs() << "Found up-to-date module at "
+                                  << modulePath
+                                  << "; deferring to serialized module loader\n");
+          return std::make_error_code(std::errc::not_supported);
+        } else if (isInResourceDir(modulePath) &&
+                   loadMode == ModuleLoadingMode::PreferSerialized) {
+          // Special-case here: If we're loading a .swiftmodule from the resource
+          // dir adjacent to the compiler, defer to the serialized loader instead
+          // of falling back. This is mainly to support development of Swift,
+          // where one might change the module format version but forget to
+          // recompile the standard library. If that happens, don't fall back
+          // and silently recompile the standard library -- instead, error like
+          // we used to.
+          LLVM_DEBUG(llvm::dbgs() << "Found out-of-date module in the "
+                                     "resource-dir at "
+                                  << modulePath
+                                  << "; deferring to serialized module loader "
+                                     "to diagnose\n");
+          return std::make_error_code(std::errc::not_supported);
+        } else {
+          LLVM_DEBUG(llvm::dbgs() << "Found out-of-date module at "
+                                  << modulePath << "\n");
+          rebuildInfo.setModuleKind(modulePath,
+                                    ModuleRebuildInfo::ModuleKind::Normal);
+        }
+      } else if (adjacentModuleBuffer.getError() != notFoundError) {
+        LLVM_DEBUG(llvm::dbgs() << "Found unreadable module at "
+                                << modulePath
+                                << "; deferring to serialized module loader\n");
+        return std::make_error_code(std::errc::not_supported);
+      }
+    }
 
     // If we have a prebuilt cache path, check that too if the interface comes
     // from the SDK.
@@ -766,53 +810,6 @@ class ModuleInterfaceLoaderImpl {
       }
     }
 
-    // [Note: ModuleInterfaceLoader-defer-to-SerializedModuleLoader]
-    // Finally, if there's a module adjacent to the .swiftinterface that we can
-    // _likely_ load (it validates OK and is up to date), bail early with
-    // errc::not_supported, so the next (serialized) loader in the chain will
-    // load it.
-    // Alternately, if there's a .swiftmodule present but we can't even
-    // read it (for whatever reason), we should let the other module loader
-    // diagnose it.
-    if (!shouldLoadAdjacentModule)
-      return notFoundError;
-
-    auto adjacentModuleBuffer = fs.getBufferForFile(modulePath);
-    if (adjacentModuleBuffer) {
-      if (serializedASTBufferIsUpToDate(modulePath, *adjacentModuleBuffer.get(),
-                                        deps)) {
-        LLVM_DEBUG(llvm::dbgs() << "Found up-to-date module at "
-                                << modulePath
-                                << "; deferring to serialized module loader\n");
-        return std::make_error_code(std::errc::not_supported);
-      } else if (isInResourceDir(modulePath) &&
-                 loadMode == ModuleLoadingMode::PreferSerialized) {
-        // Special-case here: If we're loading a .swiftmodule from the resource
-        // dir adjacent to the compiler, defer to the serialized loader instead
-        // of falling back. This is mainly to support development of Swift,
-        // where one might change the module format version but forget to
-        // recompile the standard library. If that happens, don't fall back
-        // and silently recompile the standard library -- instead, error like
-        // we used to.
-        LLVM_DEBUG(llvm::dbgs() << "Found out-of-date module in the "
-                                   "resource-dir at "
-                                << modulePath
-                                << "; deferring to serialized module loader "
-                                   "to diagnose\n");
-        return std::make_error_code(std::errc::not_supported);
-      } else {
-        LLVM_DEBUG(llvm::dbgs() << "Found out-of-date module at "
-                                << modulePath << "\n");
-        rebuildInfo.setModuleKind(modulePath,
-                                  ModuleRebuildInfo::ModuleKind::Normal);
-      }
-    } else if (adjacentModuleBuffer.getError() != notFoundError) {
-      LLVM_DEBUG(llvm::dbgs() << "Found unreadable module at "
-                              << modulePath
-                              << "; deferring to serialized module loader\n");
-      return std::make_error_code(std::errc::not_supported);
-    }
-
     // Couldn't find an up-to-date .swiftmodule, will need to build module from
     // interface.
     return notFoundError;

test/ModuleInterface/loading-order.swift

@@ -0,0 +1,41 @@
+/// Test the loading order of module interfaces between the SDK and the
+/// prebuilt cache. The order should be:
+///
+/// 1. Local cache (not tested here)
+/// 2. Next to the swiftinterface file
+/// 3. Prebuilt-module cache
+
+/// Create folders for a) our Swift module, b) the module cache, and c) a
+/// fake resource dir with a default prebuilt module cache inside.
+// RUN: %empty-directory(%t/MyModule.swiftmodule)
+// RUN: %empty-directory(%t/ModuleCache)
+// RUN: %empty-directory(%t/ResourceDir/%target-sdk-name/prebuilt-modules/MyModule.swiftmodule)
+
+/// Define two sets of public API.
+// RUN: echo 'public func nextToSwiftinterface() {}' > %t/NextToSwiftinterface.swift
+// RUN: echo 'public func prebuiltModule() {}' > %t/PrebuiltModule.swift
+
+/// Compile this into a module in the SDK.
+// RUN: %target-swift-frontend -emit-module %t/NextToSwiftinterface.swift -o %t/MyModule.swiftmodule/%target-cpu.swiftmodule -module-name MyModule -parse-stdlib -emit-module-interface-path %t/MyModule.swiftmodule/%target-cpu.swiftinterface
+
+/// Also put a module with a different API into the default prebuilt cache under the same name.
+// RUN: %target-swift-frontend -emit-module %t/PrebuiltModule.swift -o %t/ResourceDir/%target-sdk-name/prebuilt-modules/MyModule.swiftmodule/%target-cpu.swiftmodule -module-name MyModule -parse-stdlib
+
+/// Import this module and expect to use the swiftmodule next to the swiftinterface.
+// RUN: %target-swift-frontend -typecheck -resource-dir %t/ResourceDir -I %t %s -parse-stdlib -module-cache-path %t/ModuleCache -sdk %t -D FIRST_NEXT_TO_SWIFTINTERFACE
+
+/// Remove the first swiftmodule and import again to use the prebuilt swiftmodule.
+// RUN: rm %t/MyModule.swiftmodule/%target-cpu.swiftmodule
+// RUN: %target-swift-frontend -typecheck -resource-dir %t/ResourceDir -I %t %s -parse-stdlib -module-cache-path %t/ModuleCache -sdk %t -D THEN_PREBUILT_MODULE
+
+import MyModule
+
+#if FIRST_NEXT_TO_SWIFTINTERFACE
+
+nextToSwiftinterface()
+
+#elseif THEN_PREBUILT_MODULE
+
+prebuiltModule()
+
+#endif