[ModuleInterfaces] Combine the normalized target triple into the cache hash

Previously, we'd combine just the target architecture, and rely on the
fact that the .swiftinterface is in a reasonably-target-specific
subdirectory to include enough entropy to avoid hash collisions. But in
the presence of a VFS or if two targets are sharing the same
.swiftinterface file (which can sometimes happen in tests), they will
collide since the hash only includes architecture.

Instead, use the same normalization that the serialized module loader
uses, and serialize the normalized target triple instead.

Fixes rdar://55881335

Author: Harlan Haskins

lib/Frontend/ModuleInterfaceLoader.cpp

@@ -391,12 +391,15 @@ class ModuleInterfaceLoaderImpl {
     // anyways.
     H = hash_combine(H, interfacePath);
 
-    // Include the target CPU architecture. In practice, .swiftinterface files
-    // will be in architecture-specific subdirectories and would have
-    // architecture-specific pieces #if'd out. However, it doesn't hurt to
+    // Include the normalized target triple. In practice, .swiftinterface files
+    // will be in target-specific subdirectories and would have
+    // target-specific pieces #if'd out. However, it doesn't hurt to
     // include it, and it guards against mistakenly reusing cached modules
-    // across architectures.
-    H = hash_combine(H, SubInvocation.getLangOptions().Target.getArchName());
+    // across targets. Note that this normalization explicitly doesn't
+    // include the minimum deployment target (e.g. the '12.0' in 'ios12.0').
+    auto normalizedTargetTriple =
+        getTargetSpecificModuleTriple(SubInvocation.getLangOptions().Target);
+    H = hash_combine(H, normalizedTargetTriple.str());
 
     // The SDK path is going to affect how this module is imported, so include
     // it.

test/ModuleInterface/multiple-targets-same-interface.swift

@@ -0,0 +1,28 @@
+// RUN: %empty-directory(%t)
+// RUN: %empty-directory(%t/MCP)
+
+// This test makes sure that the module cache hash properly distinguishes
+// between different targets, even when the path to the module interface is
+// the same for multiple targets.
+
+// 1. Build a .swiftinterface for a dummy module.
+
+// RUN: %target-swift-frontend -typecheck -target x86_64-apple-macosx10.9 -emit-module-interface-path %t/SwiftModule.swiftinterface.tmp -parse-stdlib %s -module-name SwiftModule
+
+// 2. Remove the -target line from the .swiftinterface. Clients will build using their target.
+
+// RUN: sed -E 's/-target [^ ]+//g' %t/SwiftModule.swiftinterface.tmp > %t/SwiftModule.swiftinterface
+
+// 3. Build for a bunch of different x86_64 targets, and ensure they all succeed by putting something else in the module cache.
+
+// RUN: echo 'import SwiftModule' > %t/test.swift
+
+// RUN: %target-swift-frontend -typecheck -sdk '' -target x86_64-apple-macosx10.9 -module-cache-path %t/MCP -parse-stdlib -I %t %t/test.swift
+// RUN: %target-swift-frontend -typecheck -sdk '' -target x86_64-apple-tvos13.0   -module-cache-path %t/MCP -parse-stdlib -I %t %t/test.swift
+// RUN: %target-swift-frontend -typecheck -sdk '' -target x86_64-apple-ios10.0 -module-cache-path %t/MCP -parse-stdlib -I %t %t/test.swift
+
+// 4. Test iOS again, but with a newer minimum deployment target
+// RUN: %target-swift-frontend -typecheck -sdk '' -target x86_64-apple-ios13.0    -module-cache-path %t/MCP -parse-stdlib -I %t %t/test.swift
+
+// 5. Make sure there are only 3 .swiftmodules in the cache path (because iOS was reused)
+// RUN: ls %t/MCP/*.swiftmodule | count 3