Tests fail when the swift.cacheable_swiftmodules feature is enabled

[jschear]

To reproduce:

• Checkout 17a6eb4 (current HEAD of master)
• bazel build //tests/ios/... --features=swift.cacheable_swiftmodules

❯ bazel build //tests/ios/... --features=swift.cacheable_swiftmodules
INFO: Analyzed 199 targets (17 packages loaded, 1569 targets configured).
INFO: Found 199 targets...
ERROR: /Users/jschear/dev/rules_ios/tests/ios/unit-test/test-imports-app/BUILD.bazel:70:14: Compiling Swift module TestImports_Unit_Tests failed: (Exit 1): worker failed: error executing command 
  (cd /private/var/tmp/_bazel_jschear/7436e6242b3207e4692683d02ddfce6d/execroot/build_bazel_rules_ios && \
  exec env - \
    APPLE_SDK_PLATFORM=iPhoneSimulator \
    APPLE_SDK_VERSION_OVERRIDE=15.0 \
    XCODE_VERSION_OVERRIDE=13.0.0.13A233 \
  bazel-out/host/bin/external/build_bazel_rules_swift/tools/worker/worker swiftc @bazel-out/ios-x86_64-min12.0-applebin_ios-ios_x86_64-dbg-ST-5dc50b810145/bin/tests/ios/unit-test/test-imports-app/TestImports_Unit_Tests.swiftmodule-0.params)
Execution platform: @local_config_platform//:host
<unknown>:0: error: cannot load underlying module for 'SomeFramework'

INFO: Elapsed time: 22.734s, Critical Path: 19.91s
INFO: 18 processes: 7 internal, 8 darwin-sandbox, 1 local, 2 worker.
FAILED: Build did NOT complete successfully

I've dug into this a bit -- my current (and somewhat vague) theory is:

• Debugging data is embedded in .swiftmodules when the -serialize-debugging-options swift compiler frontend option is used.
• That data includes (absolute) swift import paths.
• In some compilations, those embedded import paths are being used by the compiler to locate dependencies.
• Those import paths would ideally instead be passed manually to the swift compiler. swift.cacheable_swiftmodules disables -serialize-debugging-options, exposing the issue.

I think #333 partially resolves this, but I can still reproduce the issue on that branch.

[jerrymarino]

@jschear thanks so much for reporting this. I can reproduce this as well 👍 What's interesting to me it doesn't provide more info about why it can't load SomeFramework

Generally the rules should work in a variety of flags, but are tested with only a subset of the permutations. This said for better coverage, maybe it makes sense to run all tests under a couple different permutations various people are using.

[jerrymarino]

@jschear I believe this issue you've reported is unrelated to virtual frameworks, mainly because I can repro this issue on a very old commit way before it was added: 549077bac7a0dfd9998309bc9c88270a70373322.

Additionally, I re-ran the example you posted and noticed there was a typo in the name ( the feature is virtualize_frameworks). After I fixed the argument to --features apple.virtualize_frameworks it fixes it.

Let me update the issue to clarify this: I think this further strengthens the case to run with various incatations of bazel config and possibly provide that as a feature

[jschear]

🤦 Sorry I mistyped! (I edited the initial report to reflect that this occurs even without the virtual frameworks feature.)