[brentleyjones]

Swift compilation repeatedly walks transitive module contexts to collect dependency artifacts for each action. Large dependency graphs pay for those traversals at every consuming target.

Propagate Swift artifacts, Clang module maps, headers, precompiled modules, and compiler plugins through depsets on SwiftInfo. Compilation, interface synthesis, and symbol graph extraction reuse those inputs, while command-line mappings stay lazy until Bazel expands them. This preserves explicit-module metadata inputs, header pruning, mixed-language inputs, and the option to load plugins only from direct dependencies.

Performance measurements (August 18, 2026):

On macOS with Bazel 9.1.1rc1, analyzing 1,491 lint-test targets in a large iOS workspace with bazel build --nobuild, running bazel clean between samples while retaining the Bazel server:

Metric	Baseline (mean of 2 warm runs)	Final simplified depset design (1 warm run)	Reduction
Command wall time	20.16s	15.27s	24%
Sampled Starlark CPU	122.62s	72.90s	41%

The individual baseline wall times were 20.84s and 19.47s; sampled Starlark CPU was 118.19s and 127.04s. CPU samples come from --starlark_cpu_profile and aggregate work across analysis threads. These results measure reanalysis, with no compilation actions executed.

The measurements compare the original implementation against 391e7a170c9c1b8d2065e0de4ec4fc6b954057f1. This PR adapts that implementation to newer upstream code; these performance measurements have not been rerun on the current PR revision.

Validation:

• All 15 Buildkite jobs passed in build #8041, including the macOS layering-check shell suite and the macOS, Linux, and Windows build/test matrix.
• 104 affected analysis and build tests passed with Bazel 9.3.1 and Xcode 27.0, covering header pruning, mixed-language targets, compiler plugins, module interfaces, symbol graphs, and private dependencies.
• test/fixtures/layering_check/layering_check_failure_test.sh passed with Bazel 9.3.1 and Xcode 27.0, covering undeclared imports and unused dependencies. Lazy module mappings preserve the existing //package:target spelling for main-repository labels in diagnostics.
• All three documentation tests passed after bazel run //doc:update.
• buildifier -mode=check -lint=warn passed for the changed Starlark files.

Two build tests could not complete under Xcode 27.0 (27A266a): //test:precompiled_modules_build_test and //test:layering_check_apple_build_test. The Swift frontend crashes with signal 11 while compiling lower_version_bin and foundation_consumer. Both crashes reproduce on unmodified main at 48869a9da892c44f9e62c754c7235ea4c6a2cede.

[adincebic]

Hmm seems that ordering changes here? Should we preserve the order? I'm not sure how much it matters in practice though.