DNM: check what the frontend is doing for some tests

Author: finagolfin

test/Serialization/module_defining_interface.swift

@@ -2,7 +2,6 @@
 // RUN: %empty-directory(%t/inputs)
 // RUN: %empty-directory(%t/test-sdk)
 // RUN: %empty-directory(%t/test-sdk/usr/lib/swift)
-// RUN: cp -r %platform-module-dir/Swift.swiftmodule %t/test-sdk/usr/lib/swift/Swift.swiftmodule
 
 // RUN: %empty-directory(%t/test-sdk/usr/lib/Foo.swiftmodule)
 // RUN: split-file %s %t

test/Serialization/module_defining_interface_client.swift

@@ -6,7 +6,6 @@
 // RUN: %empty-directory(%t/test-sdk/usr/lib/Bar.swiftmodule)
 // RUN: %empty-directory(%t/test-sdk/usr/lib/_Foo_Bar.swiftmodule)
 // RUN: %empty-directory(%t/test-sdk/usr/lib/Foo.swiftcrossimport)
-// RUN: cp -r %platform-module-dir/Swift.swiftmodule %t/test-sdk/usr/lib/swift/Swift.swiftmodule
 
 // RUN: split-file %s %t
 

test/Serialization/runtime-import-from-sdk.swift

@@ -6,13 +6,16 @@
 
 // %t/good-sdk contains a loadable standard library.
 // RUN: %empty-directory(%t/good-sdk)
-// RUN: %empty-directory(%t/good-sdk/usr/lib/swift)
+// RUN: %empty-directory(%t/good-sdk/usr/lib/swift/%target-sdk-name)
 // RUN: cp -r %platform-module-dir/Swift.swiftmodule %t/good-sdk/usr/lib/swift/Swift.swiftmodule
+// RUN: cp -r %platform-module-dir/Swift.swiftmodule %t/good-sdk/usr/lib/swift/%target-sdk-name/Swift.swiftmodule
 
 // %t/bad-sdk contains an invalid standard library that cannot be loaded.
 // RUN: %empty-directory(%t/bad-sdk)
 // RUN: %empty-directory(%t/bad-sdk/usr/lib/swift/Swift.swiftmodule)
+// RUN: %empty-directory(%t/bad-sdk/usr/lib/swift/%target-sdk-name/Swift.swiftmodule)
 // RUN: touch %t/bad-sdk/usr/lib/swift/Swift.swiftmodule/garbage-garbage-garbage.swiftmodule
+// RUN: touch %t/bad-sdk/usr/lib/swift/%target-sdk-name/Swift.swiftmodule/garbage-garbage-garbage.swiftmodule
 
 // %t/empty-toolchain does not contain a standard library.
 // RUN: %empty-directory(%t/empty-toolchain)
@@ -38,6 +41,12 @@
 // RUN: %empty-directory(%t/mcp)
 // RUN: %target-swift-frontend(mock-sdk: -sdk %t/bad-sdk) -module-cache-path %t/mcp -typecheck -verify -disable-implicit-concurrency-module-import -disable-implicit-string-processing-module-import %s
 
+// What happens if we specify an explicit resource-dir with a corrupt runtime
+// swiftmodule: is it actually used?
+
+// RUN: %empty-directory(%t/mcp)
+// RUN: %target-swift-frontend(mock-sdk: -sdk %t/good-sdk) -Xcc -v -resource-dir %t/bad-sdk/usr/lib/swift -module-cache-path %t/mcp -typecheck -verify -disable-implicit-concurrency-module-import -disable-implicit-string-processing-module-import %s
+
 // If neither the resource directory nor the SDK contains a runtime swiftmodule,
 // loading should fail. This just proves that we aren't getting runtime imports
 // some other way.
@@ -48,7 +57,6 @@
 // FIXME: We can't properly test this on a non-Darwin platform because we'll get
 // the same error message for "unloadable standard library" and "no standard
 // library" (https://github.com/apple/swift/issues/52499).
-// REQUIRES: objc_interop
 
 // RUN: %empty-directory(%t/mcp)
 // RUN: not %target-swift-frontend(mock-sdk: -sdk %t/bad-sdk) -resource-dir %t/empty-toolchain/usr/lib/swift -module-cache-path %t/mcp -typecheck %s -dump-clang-diagnostics -disable-implicit-concurrency-module-import -disable-implicit-string-processing-module-import 2>&1 | %FileCheck --check-prefix CHECK-EMPTY %s