swift explicit modules examples

[yongjincho92]

Why should we adopt explicit modules?

1. Faster build speed : Having explicit clang modules lets Bazel schedule actions more efficiently.
2. Faster LLDB debugger : Having explicit clang modules lets LLDB reuse bazel build outputs
3. Apple 🍏 : explicit modules are enabled for swift targets by default starting from Xcode 26.

Example for explicit clang module usage

This pull request introduces partial support for explicit system C module dependencies in Swift builds using Bazel (feature request can be found here #1475). The changes add new rules and attributes to propagate and manage system C modules, making it easier to handle Swift interop with C/Objective-C code, particularly when using explicit modules. It also introduces new build targets to represent system SDKs for different platforms and Xcode versions.

Key changes include:

System SDKs and C Module Support:

• Added previously deleted swift_c_module rule to wrap C targets with custom module maps for Swift interop, supporting both user-supplied and system module maps. This enables explicit C module usage in Swift targets.
• Introduced new system_sdks and testonly_system_sdks targets in system_sdks/BUILD and system_sdks/16.3.0.16E140/BUILD to represent platform-specific system SDKs, selected by Xcode version and platform constraints.

Swift Rule and Attribute Changes:

• Added a system_deps attribute to swift_library, allowing explicit specification of system module dependencies. These are automatically set to include //system_sdks:system_sdks for migration convenience.
• Updated swift_library implementation to propagate system module dependencies' SwiftInfo when the relevant features are enabled, integrating system modules into the build graph.
• Updated feature handling to support new C module features (SWIFT_FEATURE_USE_C_MODULES, SWIFT_FEATURE_EMIT_C_MODULE).

Interop Hint and Info Propagation:

• Extended swift_interop_hint and swift_interop_info to accept and propagate system_pcms, a list of precompiled Clang modules for system modules, ensuring these dependencies are correctly wired into Swift compilation.
• Updated the aspect logic to append system_pcms to the set of propagated SwiftInfo providers, ensuring system modules are available where needed.
• Added use of swift_interop_hint in example targets to demonstrate system PCM wiring.

Build and Toolchain Integration:

• Integrated new action for precompiling C modules into the toolchain configuration.

These changes lay the groundwork for robust, explicit Swift-C interop in Bazel builds, particularly as the ecosystem moves toward explicit C module adoption.

Couple things to note

1. I used swift_c_module rules which was deleted in this commit to expose system sdks to swift libraries. This rule does extra stuff and a new rule should be written for providing only necessary information to the provider.
2. I originally used @dierksen's repo rule for generating system sdks BUILD file, but moved on to adding static BUILD file for each SDK type and each Xcode type because a) the repo rule generates partially correct output which needs manual postprocessing b) even for one Xcode version, running the repo rule for each sdk takes 60 seconds on a clean slate. Ideally, we should have a rule that can create system sdks BUILD files completely and quickly. Having a standalone script that does the work would be also a good first step.
3. Also note that I only created the BUILD file for Xcode 16.3 so if you want to try out, you should have Xcode 16.3 installed locally.
4. I made some changes to swift_interop_hint and swift_library to add all found system sdks as dependencies because a) make the transition to explicit module incur less friction b) in swift objc interop, both swift library and objc library needs to depend on the same system sdk targets (otherwise, compilation fails due to duplicate definition)

What needs to be done

1. Write a rule as an alternative to swift_c_module
2. Create a programmatic way to performantly generate complete system sdks build files for an arbitrary Xcode version and sdk target platform
3. Move away from bulk passing all system sdks as deps, and pass individual system sdk target as dependencies