Test targets built with Explicitly Built Modules feature don't make use of SwiftExplicitPrecompiledModules

[chiragramani]

Repro:

1. Create a new vanilla project using the latest version of Xcode:
2. When running po in an app target, it successfully resolves .pcms from SwiftExplicitPrecompiledModules.
3. However, when running po in a test target, it behaves as if in an Implicitly Built Module environment and does not utilize SwiftExplicitPrecompiledModules. (generating new .pcms)

FB: https://feedbackassistant.apple.com/feedback/16432924

cc: @artemcm

Repro Project:
CoreA.zip

1. po inside CoreATests
2. Notice system modules .pcms being generated for iOS 10/11/12/13 targets even though the sdk version for the active target is iOS 18.1

dump-repro.txt
lldb-types-log.log.zip

[adrian-prantl]

@chiragramani Can you double-check what I'm seeing?

Both in the log file and in when I debug your reproducer locally, I only see Clang modules (.pcm) files being loaded from the explicitly built ones in SwiftExplicitPrecompiledModules.
I do see several Swift modules being rebuilt from .swiftinterface files, which I believe is due to the fact that Xcode doesn't rebuild the catalyst Swift interfaces as it does the ones from the iOS and macOS SDK. It's possible that the extra performance cost comes from that step.
The fact that new Clang modules (pcm) show up in the global module cache could be explained by e.g., the Xcode indexer working away. We could use settings set symbols.clang-modules-cache-path /some/other/path to put LLDB's clang module cache into a unique location to make sure. There's a theoretical possibility that LLDB's Clang type system might want to try to import Clang modules from the SDK, but it's unclear how that could get triggered here.

@Michael137 Would the TypeSystemClang import modules other than Foundation outside of evaluating an @import expression?

[chiragramani]

@chiragramani Can you double-check what I'm seeing?

Yes, you're right. I do see a few .pcm files being loaded from the explicitly built ones in SwiftExplicitPrecompiledModules.

We could use settings set symbols.clang-modules-cache-path /some/other/path to put LLDB's clang module cache into a unique location to make sure.

I just tested it and confirmed that the new .pcm files are being loaded while respecting the minimum OS versions of the images found in the LLDB dump(and not the target for which explicit modules were built). This suggests that your theory about the LLDB's Clang type system trying to import Clang modules from the SDK could be correct.

[chiragramani]

@adrian-prantl @Michael137 Do you have any suggestions on how we can further reduce the generation of extra .pcms in the case mentioned above?

[adrian-prantl]

We tried this out on our end and it looks like the Clang modules produced where dependencies of .swiftinterface files from the SDK that were being compiled to .swiftmodule files and cached. Could you maybe run sample lldb-rpc-server 60 while reproducing this on your end just so we can confirm that what we were seeing in our setup matches what you are seeing?

[chiragramani]

We tried this out on our end and it looks like the Clang modules produced where dependencies of .swiftinterface files from the SDK that were being compiled to .swiftmodule files and cached. Could you maybe run sample lldb-rpc-server 60 while reproducing this on your end just so we can confirm that what we were seeing in our setup matches what you are seeing?

Thanks for looking into this. I believe I’m seeing something similar on my end. Enclosing the trace below for reference:

lldb-rpc-server_2025-02-20_114824_fQju.sample.txt.zip

Let me know if you need any further details.