The choice to pass compilation_contexts separately was a trade-off. The compilation contexts nested inside the Clang modules aren't easily suitable for use here. We can't rely on only the direct modules' CCs because information that should still get propagated—like defines and include paths—would get lost when passing through any objc_library that doesn't export a module. And we don't want to process the full set of transitive modules' CCs for each compile action, as this would be a significant performance hit. The only other option considered was to propagate a copy of the CC at the top level of SwiftInfo, even for no-module objc_library targets, but there were concerns about performance here as well, and whether that context would drift from the real one.
Even with the extra argument, this change makes the compilation API more flexible by removing the assumption that compilation requirements must be expressed as Targets. For example, removing the assumption that dependencies propagate SwiftInfo directly allows the API to be used inside aspects where the SwiftInfo providers may need to be wrapped by a custom provider in order to avoid collisions.
PiperOrigin-RevId: 424979602
(cherry picked from commit bfcae19af93924651911e6bdc669608e9453a774)
Cherry-pick notes: In swift_common.compile we take in cc_infos and objc_infos instead of compilation_contexts since we still need merged linking information to support -disable-autolink-framework. If we ever remove that feature, we should change compile to match upstream.
The choice to pass
compilation_contextsseparately was a trade-off. The compilation contexts nested inside the Clang modules aren't easily suitable for use here. We can't rely on only the direct modules' CCs because information that should still get propagated—like defines and include paths—would get lost when passing through anyobjc_librarythat doesn't export a module. And we don't want to process the full set of transitive modules' CCs for each compile action, as this would be a significant performance hit. The only other option considered was to propagate a copy of the CC at the top level ofSwiftInfo, even for no-moduleobjc_librarytargets, but there were concerns about performance here as well, and whether that context would drift from the real one.Even with the extra argument, this change makes the compilation API more flexible by removing the assumption that compilation requirements must be expressed as
Targets. For example, removing the assumption that dependencies propagateSwiftInfodirectly allows the API to be used inside aspects where theSwiftInfoproviders may need to be wrapped by a custom provider in order to avoid collisions.PiperOrigin-RevId: 424979602 (cherry picked from commit bfcae19af93924651911e6bdc669608e9453a774)
Cherry-pick notes: In
swift_common.compilewe take incc_infosandobjc_infosinstead ofcompilation_contextssince we still need merged linking information to support-disable-autolink-framework. If we ever remove that feature, we should changecompileto matchupstream.