[test] Handle architecture aliasing for OpenBSD.

Swift calls the architecture x86_64, OpenBSD calls it amd64. If we use
run_cpu in lit.cfg as-is, then we may need to duplicate lines in each
test for 'x86_64' and 'amd64', which puts a maintenance burden on unit
test developers to ensure they are duplicating changes to each line.

Instead, alias 'amd64' to 'x86_64' for `run_cpu`, but keep the platform
module path referring to 'amd64', in order to distinguish the target
architecture name and the Swift architecture name. This is particularly
relevant for the %target-.*-name pseudovariables used, which should
reference the Swift architecture names.

However, some unit tests are directly referencing %target-cpu directly,
which would break the aliasing. This is done only for swiftinterface
files, so a new substitution is defined in lit.cfg for these variables,
and the affected unit test cases are migrated.
This commit is contained in:
3405691582
2020-03-20 20:03:45 -04:00
parent 409603c61d
commit c8ba437444
9 changed files with 26 additions and 20 deletions

View File

@@ -5,11 +5,11 @@
// RUN: echo 'public func showsUpInBothPlaces() {}' > %t/Lib.swift
// 1. Create a .swiftinterface file containing just one API, and put it inside a second build dir (without a .swiftmodule)
// RUN: %target-swift-frontend -typecheck %t/Lib.swift -emit-module-interface-path %t/SecondBuildDir/Lib.framework/Modules/Lib.swiftmodule/%target-cpu.swiftinterface -module-name Lib
// RUN: %target-swift-frontend -typecheck %t/Lib.swift -emit-module-interface-path %t/SecondBuildDir/Lib.framework/Modules/Lib.swiftmodule/%target-swiftinterface-name -module-name Lib
// 2. Add a new API to the module, and compile just the serialized version in the build dir.
// RUN: echo 'public func onlyInTheCompiledModule() {}' >> %t/Lib.swift
// RUN: %target-swift-frontend -emit-module %t/Lib.swift -o %t/BuildDir/Lib.framework/Modules/Lib.swiftmodule/%target-cpu.swiftmodule -emit-module-interface-path %t/BuildDir/Lib.framework/Modules/Lib.swiftmodule/%target-cpu.swiftinterface -module-name Lib
// RUN: %target-swift-frontend -emit-module %t/Lib.swift -o %t/BuildDir/Lib.framework/Modules/Lib.swiftmodule/%target-swiftmodule-name -emit-module-interface-path %t/BuildDir/Lib.framework/Modules/Lib.swiftmodule/%target-swiftinterface-name -module-name Lib
// 3. Make sure when we compile this test file, we can access both APIs since we'll
// load the compiled .swiftmodule instead of the .swiftinterface in the SDK.
@@ -19,7 +19,7 @@
// RUN: ls %t/ModuleCache | not grep 'swiftmodule'
// 5. This should also work if the swiftinterface isn't present in the first build dir.
// RUN: rm %t/BuildDir/Lib.framework/Modules/Lib.swiftmodule/%target-cpu.swiftinterface
// RUN: rm %t/BuildDir/Lib.framework/Modules/Lib.swiftmodule/%target-swiftinterface-name
// RUN: %target-swift-frontend -typecheck %s -F %t/BuildDir -F %t/SecondBuildDir -module-cache-path %t/ModuleCache
// 6. Make sure we /still/ didn't compile any .swiftinterfaces into the module cache.