Bazel Central Registry

@rules_swift@rules_swift//doc:api.bzl

Re-exports of API symbols for stardoc.

Functions & Macros

create_swift_interop_info

Returns a provider that lets a target expose C/Objective-C APIs to Swift.

The provider returned by this function allows custom build rules written in
Starlark to be uninvolved with much of the low-level machinery involved in
making a Swift-compatible module. Such a target should propagate a CcInfo
provider whose compilation context contains the headers that it wants to
make into a module, and then also propagate the provider returned from this
function.

The simplest usage is for a custom rule to do the following:

Add swift_clang_module_aspect to any attribute that provides
dependencies of the code that needs to interop with Swift (typically
deps, but could be other attributes as well, such as attributes
providing additional support libraries).
Have the rule implementation call create_swift_interop_info, passing
it only the list of SwiftInfo providers from its dependencies. This
tells swift_clang_module_aspect when it runs on this rule's target
to derive the module name from the target label and create a module map
using the headers from the compilation context of the CcInfo you
propagate.

If the custom rule has reason to provide its own module name or module map,
then it can do so using the module_name and module_map arguments.

When a rule returns this provider, it must provide the full set of
SwiftInfo providers from dependencies that will be merged with the one
that swift_clang_module_aspect creates for the target itself. The aspect
will not collect dependency providers automatically. This allows the
rule to not only add extra dependencies (such as support libraries from
implicit attributes) but also to exclude dependencies if necessary.

Parameters

`compilation_context`	A `CcCompilationContext` that provides the headers for the module, or `None` (the default) if the headers should be derived from the target's `CcInfo` provider. This should only be used if a target explicitly needs to use a different compilation context for Swift than it does for C/Objective-C, which is a very rare situation. Default: `None`
`direct_swift_infos`	A list of `SwiftInfo` providers from dependencies, which will be merged with the new `SwiftInfo` created by the aspect as direct data. Default: `[]`
`exclude_headers`	A `list` of `File`s representing headers that should be excluded from the module if the module map is generated. Default: `[]`
`module_map`	A `File` representing an existing module map that should be used to represent the module, or `None` (the default) if the module map should be generated based on the headers in the target's compilation context. If this argument is provided, then `module_name` must also be provided. Default: `None`
`module_name`	A string denoting the name of the module, or `None` (the default) if the name should be derived automatically from the target label. Default: `None`
`requested_features`	A list of features (empty by default) that should be requested for the target, which are added to those supplied in the `features` attribute of the target. These features will be enabled unless they are otherwise marked as unsupported (either on the target or by the toolchain). This allows the rule implementation to have additional control over features that should be supported by default for all instances of that rule as if it were creating the feature configuration itself. Default: `[]`
`suppressed`	A `bool` indicating whether the module that the aspect would create for the target should instead be suppressed. Default: `False`
`swift_infos`	A list of `SwiftInfo` providers from dependencies, which will be merged with the new `SwiftInfo` created by the aspect. Default: `[]`
`unsupported_features`	A list of features (empty by default) that should be considered unsupported for the target, which are added to those supplied as negations in the `features` attribute. This allows the rule implementation to have additional control over features that should be disabled by default for all instances of that rule as if it were creating the feature configuration itself. Default: `[]`

derive_swift_module_name

Returns a derived module name from the given build label.

For targets whose module name is not explicitly specified, the module name
is computed using the following algorithm:

The package and name components of the label are considered separately.
All interior sequences of non-identifier characters (anything other
than a-z, A-Z, 0-9, and _) are replaced by a single underscore
(_). Any leading or trailing non-identifier characters are dropped.
If the package component is non-empty after the above transformation,
it is joined with the transformed name component using an underscore.
Otherwise, the transformed name is used by itself.
If this would result in a string that begins with a digit (0-9), an
underscore is prepended to make it identifier-safe.

This mapping is intended to be fairly predictable, but not reversible.

Parameters

`feature_configuration`	The Swift feature configuration being used when compiling the target. This currently does nothing; it will be used by upcoming changes to manage the migration of module names to raw identifiers that use the Bazel target label. Default: `None`
`args`	Either a single argument of type `Label`, or two arguments of type `str` where the first argument is the package name and the second argument is the target name.

is_swift_overlay

Returns a value indicating whether the given target is a swift_overlay.

This is meant to be used by aspects that visit the aspect_hints of a
target to identify the swift_overlay target (if present) without making
the provider public or requiring those aspects to propagate the information
themselves.

Parameters

*target

A Target; for example, an element of
ctx.rule.attr.aspect_hints accessed inside an aspect.

swift_common.cc_feature_configuration

Returns the C++ feature configuration in a Swift feature configuration.

Parameters

*feature_configuration

The Swift feature configuration, as returned from
configure_features.

swift_common.compile

Compiles a Swift module.

Parameters

`*actions`	The context's `actions` object.
`additional_inputs`	A list of `File`s representing additional input files that need to be passed to the Swift compile action because they are referenced by compiler flags. Default: `[]`
`*cc_infos`	A list of `CcInfo` providers that represent C/Objective-C requirements of the target being compiled, such as Swift-compatible preprocessor defines, header search paths, and so forth. These are typically retrieved from a target's dependencies.
`copts`	A list of compiler flags that apply to the target being built. These flags, along with those from Bazel's Swift configuration fragment (i.e., `--swiftcopt` command line flags) are scanned to determine whether whole module optimization is being requested, which affects the nature of the output files. Default: `[]`
`defines`	Symbols that should be defined by passing `-D` to the compiler. Default: `[]`
`exec_group`	Runs the Swift compilation action under the given execution group's context. If `None`, the default execution group is used. Default: `None`
`extra_swift_infos`	Extra `SwiftInfo` providers that aren't contained by the `deps` of the target being compiled but are required for compilation. Default: `[]`
`*feature_configuration`	A feature configuration obtained from `configure_features`.
`generated_header_name`	The name of the Objective-C generated header that should be generated for this module. If omitted, no header will be generated. Default: `None`
`is_test`	Deprecated. This argument will be removed in the next major release. Use the `include_dev_srch_paths` attribute instead. Represents if the `testonly` value of the context. Default: `None`
`include_dev_srch_paths`	A `bool` that indicates whether the developer framework search paths will be added to the compilation command. Default: `None`
`*module_name`	The name of the Swift module being compiled. This must be present and valid; use `derive_swift_module_name` to generate a default from the target's label if needed.
`*package_name`	The semantic package of the name of the Swift module being compiled.
`plugins`	A list of `SwiftCompilerPluginInfo` providers that represent plugins that should be loaded by the compiler. Default: `[]`
`private_cc_infos`	A list of `CcInfos`s that represent private (non-propagated) C/Objective-C requirements of the target being compiled, such as Swift-compatible preprocessor defines, header search paths, and so forth. These are typically retrieved from a target's `private_deps`. Default: `[]`
`private_swift_infos`	A list of `SwiftInfo` providers from private (implementation-only) dependencies of the target being compiled. The modules defined by these providers are used as dependencies of the Swift module being compiled but not of the Clang module for the generated header. Default: `[]`
`*srcs`	The Swift source files to compile.
`*swift_infos`	A list of `SwiftInfo` providers from non-private dependencies of the target being compiled. The modules defined by these providers are used as dependencies of both the Swift module being compiled and the Clang module for the generated header.
`swift_toolchain`	The `SwiftToolchainInfo` provider of the toolchain. Default: `None`
`*target_name`	The name of the target for which the code is being compiled, which is used to determine unique file paths for the outputs.
`toolchains`	The struct containing the Swift and C++ toolchain providers, as returned by `swift_common.find_all_toolchains()`. Default: `None`
`toolchain_type`	The toolchain type of the `swift_toolchain` which is used for the proper selection of the execution platform inside `run_toolchain_action`. Default: `Label("@rules_swift//toolchains:toolchain_type")`
`*workspace_name`	The name of the workspace for which the code is being compiled, which is used to determine unique file paths for some outputs.

swift_common.compile_module_interface

Compiles a Swift module interface.

Parameters

`*actions`	The context's `actions` object.
`additional_inputs`	A list of `File`s that should be available to the compile action in the sandbox but are not referenced on the command line. The typical use case is making a sibling `.private.swiftinterface` available alongside the public `.swiftinterface` so the compiler can resolve SPI references during the textual-interface build. Default: `[]`
`clang_module`	An optional underlying Clang module (as returned by `create_clang_module_inputs`), if present for this Swift module. Default: `None`
`*compilation_contexts`	A list of `CcCompilationContext`s that represent C/Objective-C requirements of the target being compiled, such as Swift-compatible preprocessor defines, header search paths, and so forth. These are typically retrieved from the `CcInfo` providers of a target's dependencies.
`copts`	A list of compiler flags that apply to the target being built. Default: `[]`
`exec_group`	Runs the Swift compilation action under the given execution group's context. If `None`, the default execution group is used. Default: `None`
`*feature_configuration`	A feature configuration obtained from `configure_features`.
`is_framework`	True if this module is a Framework module, false othwerise. Default: `False`
`*module_name`	The name of the Swift module being compiled. This must be present and valid; use `derive_swift_module_name` to generate a default from the target's label if needed.
`*swiftinterface_file`	The Swift module interface file to compile.
`*swift_infos`	A list of `SwiftInfo` providers from dependencies of the target being compiled.
`swift_toolchain`	The `SwiftToolchainInfo` provider of the toolchain. Default: `None`
`*target_name`	The name of the target for which the interface is being compiled, which is used to determine unique file paths for the outputs.
`toolchains`	The struct containing the Swift and C++ toolchain providers, as returned by `swift_common.find_all_toolchains()`. Default: `None`
`toolchain_type`	The toolchain type of the `swift_toolchain` which is used for the proper selection of the execution platform inside `run_toolchain_action`. Default: `Label("@rules_swift//toolchains:toolchain_type")`

swift_common.configure_features

Creates a feature configuration to be passed to Swift build APIs.

This function calls through to cc_common.configure_features to configure
underlying C++ features as well, and nests the C++ feature configuration
inside the Swift one. Users who need to call C++ APIs that require a feature
configuration can extract it by calling
get_cc_feature_configuration(feature_configuration).

Parameters

`*ctx`	The rule context.
`swift_toolchain`	The `SwiftToolchainInfo` provider of the toolchain being used to build. This is used to determine features that are enabled by default or unsupported by the toolchain, and the C++ toolchain associated with the Swift toolchain is used to create the underlying C++ feature configuration. Default: `None`
`toolchains`	The toolchains that are used to determine which features are enabled by default or unsupported. This is typically obtained using `swift_common.find_all_toolchains()`. Default: `None`
`requested_features`	The list of features to be enabled. This is typically obtained using the `ctx.features` field in a rule implementation function. Default: `[]`
`unsupported_features`	The list of features that are unsupported by the current rule. This is typically obtained using the `ctx.disabled_features` field in a rule implementation function. Default: `[]`

swift_common.create_compilation_context

Cretes a compilation context for a Swift target.

Parameters

`*defines`	A list of defines
`*srcs`	A list of Swift source files used to compile the target.
`*transitive_modules`	A list of modules (as returned by `create_swift_module_context`) from the transitive dependencies of the target.

swift_common.create_linking_context_from_compilation_outputs

Creates a linking context from the outputs of a Swift compilation.

On some platforms, this function will spawn additional post-compile actions
for the module in order to add their outputs to the linking context. For
example, if the toolchain that requires a "module-wrap" invocation to embed
the .swiftmodule into an object file for debugging purposes, or if it
extracts auto-linking information from the object files to generate a linker
command line parameters file, those actions will be created here.

Parameters

`*actions`	The context's `actions` object.
`additional_inputs`	A `list` of `File`s containing any additional files that are referenced by `user_link_flags` and therefore need to be propagated up to the linker. Default: `[]`
`alwayslink`	If `False`, any binary that depends on the providers returned by this function will link in all of the library's object files only if there are symbol references. See the discussion on `swift_library` `alwayslink` for why that behavior could result in undesired results. If `True`, the opposite will happen and this library will be -force_load into the link actions that depend on it. Defaults to `True`. Default: `True`
`*compilation_outputs`	A `CcCompilationOutputs` value containing the object files to link. Typically, this is the second tuple element in the value returned by `compile`.
`*feature_configuration`	A feature configuration obtained from `configure_features`.
`is_test`	Deprecated. This argument will be removed in the next major release. Use the `include_dev_srch_paths` attribute instead. Represents if the `testonly` value of the context. Default: `None`
`include_dev_srch_paths`	A `bool` that indicates whether the developer framework search paths will be added to the compilation command. Default: `None`
`*label`	The `Label` of the target being built. This is used as the owner of the linker inputs created for post-compile actions (if any), and the label's name component also determines the name of the artifact unless it is overridden by the `name` argument.
`linking_contexts`	A `list` of `CcLinkingContext`s containing libraries from dependencies. Default: `[]`
`*module_context`	The module context returned by `compile` containing information about the Swift module that was compiled. Typically, this is the first tuple element in the value returned by `compile`.
`name`	A string that is used to derive the name of the library or libraries linked by this function. If this is not provided or is a falsy value, the name component of the `label` argument is used. Default: `None`
`swift_toolchain`	The `SwiftToolchainInfo` provider of the toolchain. Default: `None`
`toolchains`	The struct containing the Swift and C++ toolchain providers, as returned by `swift_common.find_all_toolchains()`. Default: `None`
`toolchain_type`	The toolchain type of the `swift_toolchain` which is used for the proper selection of the execution platform inside `run_toolchain_action`. Default: `Label("@rules_swift//toolchains:toolchain_type")`
`user_link_flags`	A `list` of strings containing additional flags that will be passed to the linker for any binary that links with the returned linking context. Default: `[]`

swift_common.extract_symbol_graph

Extracts the symbol graph from a Swift module.

Parameters

`*actions`	The object used to register actions.
`*compilation_contexts`	A list of `CcCompilationContext`s that represent C/Objective-C requirements of the target being compiled, such as Swift-compatible preprocessor defines, header search paths, and so forth. These are typically retrieved from the `CcInfo` providers of a target's dependencies.
`emit_extension_block_symbols`	A `bool` that indicates whether `extension` block information should be included in the symbol graph. Default: `None`
`exec_group`	Runs the Swift compilation action under the given execution group's context. If `None`, the default execution group is used. Default: `None`
`*feature_configuration`	The Swift feature configuration.
`*include_dev_srch_paths`	A `bool` that indicates whether the developer framework search paths will be added to the compilation command.
`minimum_access_level`	The minimum access level of the declarations that should be extracted into the symbol graphs. The default value is `None`, which means the Swift compiler's default behavior should be used (at the time of this writing, the default behavior is "public"). Default: `None`
`*module_name`	The name of the module whose symbol graph should be extracted.
`*output_dir`	A directory-type `File` into which `.symbols.json` files representing the module's symbol graph will be extracted. If extraction is successful, this directory will contain a file named `${MODULE_NAME}.symbols.json`. Optionally, if the module contains extensions to types in other modules, then there will also be files named `${MODULE_NAME}@${EXTENDED_MODULE}.symbols.json`.
`*swift_infos`	A list of `SwiftInfo` providers from dependencies of the target being compiled. This should include both propagated and non-propagated (implementation-only) dependencies.
`swift_toolchain`	The `SwiftToolchainInfo` provider of the toolchain. Default: `None`
`toolchains`	The struct containing the Swift and C++ toolchain providers, as returned by `swift_common.find_all_toolchains()`. Default: `None`
`toolchain_type`	The toolchain type of the `swift_toolchain` which is used for the proper selection of the execution platform inside `run_toolchain_action`. Default: `Label("@rules_swift//toolchains:toolchain_type")`

swift_common.find_all_toolchains

Finds all toolchains required to build Swift code.

The Swift build APIs require the C++ toolchain to link libraries and
binaries, so this function finds both and returns them in a convenient
structure that should be passed to the other build APIs.

Parameters

`*ctx`	The rule or aspect context.
`exec_group`	The name of the execution group that contains the Swift toolchain. If this is provided and the toolchain is not declared in that execution group, it will be looked up from `ctx` as a fallback instead. If this argument is `None` (the default), then the Swift toolchain will only be looked up from `ctx.` Default: `None`
`mandatory`	If `False`, this function will return `None` instead of failing if no toolchain is found. Defaults to `True`. Default: `True`
`toolchain_type`	The Swift toolchain type to use. Defaults to the standard Swift toolchain type. Default: `Label("@rules_swift//toolchains:toolchain_type")`

swift_common.get_toolchain

Gets the Swift toolchain associated with the rule or aspect.

WARNING: This function is deprecated and will be removed soon. Use
swift_common.find_all_toolchains() instead to request the Swift and the
C++ toolchains.

Parameters

`*ctx`	The rule or aspect context.
`exec_group`	The name of the execution group that should contain the toolchain. If this is provided and the toolchain is not declared in that execution group, it will be looked up from `ctx` as a fallback instead. If this argument is `None` (the default), then the toolchain will only be looked up from `ctx.` Default: `None`
`mandatory`	If `False`, this function will return `None` instead of failing if no toolchain is found. Defaults to `True`. Default: `True`
`toolchain_type`	The toolchain type to use. Defaults to the standard Swift toolchain type. Default: `Label("@rules_swift//toolchains:toolchain_type")`
`attr`	The name of the attribute on the calling rule or aspect that should be used to retrieve the toolchain if it is not provided by the `toolchains` argument of the rule/aspect. Note that this is only supported for legacy/migration purposes and will be removed once migration to toolchains is complete. Default: `"_toolchain"`

swift_common.is_action_enabled

Returns True if the given action is enabled in the Swift toolchain.

This function should be used before invoking APIs that invoke actions that
might not be available depending on the version of the Swift toolchain. For
example, SwiftSynthesizeInterface actions (created by calling
swift_common.synthesize_interface) are only available starting from Swift
6.1.

Parameters

`*action_name`	The name of the action, which corresponds to the action's mnemonic (for example, `SwiftSynthesizeInterface`).
`swift_toolchain`	The Swift toolchain being used to build. Default: `None`
`toolchains`	The struct containing the Swift and C++ toolchain providers, as returned by `swift_common.find_all_toolchains()`. Default: `None`

swift_common.is_enabled

Returns True if the feature is enabled in the feature configuration.

This function handles both Swift-specific features and C++ features so that
users do not have to manually extract the C++ configuration in order to
check it.

Parameters

`*feature_configuration`	The Swift feature configuration, as returned by `configure_features`.
`*feature_name`	The name of the feature to check.

swift_common.precompile_clang_module

Precompiles an explicit Clang module that is compatible with Swift.

Parameters

`*actions`	The context's `actions` object.
`*cc_compilation_context`	A `CcCompilationContext` that contains headers and other information needed to compile this module. This compilation context should contain all headers required to compile the module, which includes the headers for the module itself and any others that must be present on the file system/in the sandbox for compilation to succeed. The latter typically refers to the set of headers of the direct dependencies of the module being compiled, which Clang needs to be physically present before it detects that they belong to one of the precompiled module dependencies.
`exec_group`	Runs the Swift compilation action under the given execution group's context. If `None`, the default execution group is used. Default: `None`
`*feature_configuration`	A feature configuration obtained from `configure_features`.
`*module_map_file`	A textual module map file that defines the Clang module to be compiled.
`*module_name`	The name of the top-level module in the module map that will be compiled.
`swift_toolchain`	The `SwiftToolchainInfo` provider of the toolchain. Default: `None`
`*target_name`	The name of the target for which the code is being compiled, which is used to determine unique file paths for the outputs.
`toolchains`	The struct containing the Swift and C++ toolchain providers, as returned by `swift_common.find_all_toolchains()`. Default: `None`
`toolchain_type`	The toolchain type of the Swift toolchain. Default: `Label("@rules_swift//toolchains:toolchain_type")`
`swift_infos`	A list of `SwiftInfo` providers representing dependencies required to compile this module. Default: `[]`
`user_compile_flags`	Additional Clang flags to pass to the precompile action. Each flag is forwarded to the underlying clang invocation via `-Xcc`. Default: `[]`

swift_common.synthesize_interface

Extracts the symbol graph from a Swift module.

Parameters

`*actions`	The object used to register actions.
`*compilation_contexts`	A list of `CcCompilationContext`s that represent C/Objective-C requirements of the target being compiled, such as Swift-compatible preprocessor defines, header search paths, and so forth. These are typically retrieved from the `CcInfo` providers of a target's dependencies.
`*feature_configuration`	The Swift feature configuration.
`*module_name`	The name of the module whose symbol graph should be extracted.
`*output_file`	A `File` into which the synthesized interface will be written.
`*swift_infos`	A list of `SwiftInfo` providers from dependencies of the target being compiled. This should include both propagated and non-propagated (implementation-only) dependencies.
`swift_toolchain`	The `SwiftToolchainInfo` provider of the toolchain. Default: `None`
`toolchains`	The struct containing the Swift and C++ toolchain providers, as returned by `swift_common.find_all_toolchains()`. Default: `None`
`toolchain_type`	The toolchain type of the `swift_toolchain` which is used for the proper selection of the execution platform inside `run_toolchain_action`. Default: `Label("@rules_swift//toolchains:toolchain_type")`

swift_common.use_all_toolchains

Returns a list of toolchain types required to build Swift code.

The Swift build APIs require the C++ toolchain to link libraries and
binaries, so this function requests both for convenience.

This function returns a list so that it can be easily composed with other
toolchains if necessary. For example, a rule that requires toolchains other
than Swift and C++ could write:

toolchains = swift_common.use_all_toolchains() + [other toolchains...]

Parameters

`mandatory`	Whether or not it should be an error if the toolchain cannot be resolved. Defaults to True. Default: `True`
`toolchain_type`	The Swift toolchain type to use. Defaults to the standard Swift toolchain type. Default: `Label("@rules_swift//toolchains:toolchain_type")`

swift_common.use_toolchain

Returns a list of toolchain types needed to use the Swift toolchain.

WARNING: This function is deprecated and will be removed soon. Use
swift_common.find_all_toolchains() instead to request the Swift and the
C++ toolchains.

This function returns a list so that it can be easily composed with other
toolchains if necessary. For example, a rule with multiple toolchain
dependencies could write:

toolchains = use_swift_toolchain() + [other toolchains...]

Parameters

`mandatory`	Whether or not it should be an error if the toolchain cannot be resolved. Defaults to True. Default: `True`
`toolchain_type`	The toolchain type to use. Defaults to the standard Swift toolchain type. Default: `Label("@rules_swift//toolchains:toolchain_type")`

@rules_swift@rules_swift//doc:rules.bzl

Bazel rules to define Swift libraries and executable binaries.

Users should load these rules from .bzl files under the swift and proto
directories. Do not import definitions from the internal subdirectory
directly.

For example:

load("@rules_swift//swift:swift_library.bzl", "swift_library")
load("@rules_swift//proto:swift_proto_library.bzl", "swift_proto_library")

Functions & Macros

mixed_language_library

Creates a mixed language library from a Clang and Swift library target pair.

Note: In the future swift_library will support mixed-language libraries.
Once that is the case, this macro will be deprecated.

Parameters

`*name`	The name of the target.
`additional_objc_compiler_inputs`	Additional files that are referenced using `$(location ...)` in attributes that support location expansion. Default: `[]`
`always_include_developer_search_paths`	If `True`, the developer framework search paths will be added to the swift compilation command. This enables a Swift module to access `XCTest` without having to mark the target as `testonly = True`. Default: `False`
`alwayslink`	If true, any binary that depends (directly or indirectly) on this library will link in all the object files for the files listed in `clang_srcs` and `swift_srcs`, even if some contain no symbols referenced by the binary. This is useful if your code isn't explicitly called by code in the binary; for example, if you rely on runtime checks for protocol conformances added in extensions in the library but do not directly reference any other symbols in the object file that adds that conformance. Default: `False`
`clang_copts`	The compiler flags for the clang library. These will only be used for the clang library. If you want them to affect the swift library as well, you need to pass them with `-Xcc` in `swift_copts`. Default: `[]`
`clang_defines`	Extra clang `-D` flags to pass to the compiler. They should be in the form `KEY=VALUE` or simply `KEY` and are passed not only to the compiler for this target (as `clang_copts` are) but also to all dependers of this target. Subject to "Make variable" substitution and Bourne shell tokenization. Default: `[]`
`clang_deps`	A list of targets that are dependencies of only the clang library. Default: `[]`
`*clang_srcs`	The list of C, C++, Objective-C, or Objective-C++ sources for the clang library.
`data`	The list of files needed by this target at runtime. Files and targets named in the `data` attribute will appear in the `*.runfiles` area of this target, if it has one. This may include data files needed by a binary or library, or other programs needed by it. Default: `[]`
`enable_modules`	Enables clang module support (via `-fmodules`). Setting this to `True` will allow you to `@import` system headers and other targets: `@import UIKit;` `@import path_to_package_target;`. Default: `False`
`hdrs`	The list of C, C++, Objective-C, or Objective-C++ header files published by this library to be included by sources in dependent rules. This can't include `umbrella_header`. Default: `[]`
`includes`	List of `#include`/`#import` search paths to add to this target and all depending targets. Default: `[]`
`linkopts`	Extra flags to pass to the linker. Default: `[]`
`module_map`	A `File` representing an existing module map that should be used to represent the module, or `None` (the default) if the module map should be generated based on `hdrs`. If this argument is provided, then `module_name` must also be provided. Warning: If a module map (whether provided here or not) is able to be found via an include path, it will result in duplicate module definition errors for downstream targets unless sandboxing or remote execution is used. Default: `None`
`module_name`	The name of the Swift module being built. If left unspecified, the module name will be computed based on the target's build label, by stripping the leading `//` and replacing `/`, `:`, and other non-identifier characters with underscores. Default: `None`
`non_arc_srcs`	The list of Objective-C files that are processed to create the library target that DO NOT use ARC. The files in this attribute are treated very similar to those in the `clang_srcs` attribute, but are compiled without ARC enabled. Default: `[]`
`package_name`	The semantic package of the Swift target being built. Targets with the same `package_name` can access APIs using the 'package' access control modifier in Swift 5.9+. Default: `None`
`private_deps`	A list of targets that are implementation-only dependencies of the target being built. Libraries/linker flags from these dependencies will be propagated to dependent for linking, but artifacts/flags required for compilation (such as .swiftmodule files, C headers, and search paths) will not be propagated. Default: `[]`
`sdk_dylibs`	A list of of SDK `.dylib` libraries to link with. For instance, "libz" or "libarchive". "libc++" is included automatically if the binary has any C++ or Objective-C++ sources in its dependency tree. When linking a binary, all libraries named in that binary's transitive dependency graph are used. Default: `[]`
`sdk_frameworks`	A list of SDK frameworks to link with (e.g. "AddressBook", "QuartzCore"). When linking a top level Apple binary, all SDK frameworks listed in that binary's transitive dependency graph are linked. Default: `[]`
`swift_copts`	The compiler flags for the swift library. Default: `[]`
`swift_defines`	A list of Swift defines to add to the compilation command line. Note that unlike C-family languages, Swift defines do not have values; they are simply identifiers that are either defined or undefined. So strings in this list should be simple identifiers, not `name=value` pairs. Each string is prepended with `-D` and added to the command line. Unlike `swift_copts`, these flags are added for the target and every target that depends on it, so use this attribute with caution. It is preferred that you add defines directly to `swift_copts`, only using this feature in the rare case that a library needs to propagate a symbol up to those that depend on it. Default: `[]`
`swift_plugins`	A list of Swift plugins for the swift library. Default: `[]`
`*swift_srcs`	The sources for the swift library.
`swiftc_inputs`	Additional files that are referenced using `$(location ...)` in attributes that support location expansion. Default: `[]`
`textual_hdrs`	The list of C, C++, Objective-C, or Objective-C++ files that are included as headers by source files in this rule or by users of this library. Unlike `hdrs`, these will not be compiled separately from the sources. Default: `[]`
`umbrella_header`	A `File` representing an existing umbrella header that should be used in the generated module map or is used in the custom module map, or `None` (the default) if the umbrella header should be generated based on `hdrs`. A symlink to this header is added to an include path such that `#import <ModuleName/ModuleName.h>` works for this and downstream targets. Default: `None`
`weak_sdk_frameworks`	A list of SDK frameworks to weakly link with. For instance, "MediaAccessibility". In difference to regularly linked SDK frameworks, symbols from weakly linked frameworks do not cause an error if they are not present at runtime. Default: `[]`
`deps`	A list of targets that are dependencies of the target being built. Default: `[]`
`kwargs`	Additional arguments to pass to the underlying clang and swift library targets.

Rules

swift_binary

Compiles and links Swift code into an executable binary.

On Linux, this rule produces an executable binary for the desired target
architecture.

On Apple platforms, this rule produces a single-architecture binary; it does
not produce universal binaries. As such, this rule is mainly useful for
creating Swift tools intended to run on the local build machine.

If you want to create a multi-architecture binary or a bundled application,
please use one of the platform-specific application rules in
rules_apple instead of
swift_binary.

Attribute	Type	Description
`*name`	`name`	A unique name for this target.
`data`	`list of labels`	The list of files needed by this target at runtime. Files and targets named in the `data` attribute will appear in the `*.runfiles` area of this target, if it has one. This may include data files needed by a binary or library, or other programs needed by it. Default: `[]`
`deps`	`list of labels`	A list of targets that are dependencies of the target being built, which will be linked into that target. If the Swift toolchain supports implementation-only imports (`private_deps` on `swift_library`), then targets in `deps` are treated as regular (non-implementation-only) imports that are propagated both to their direct and indirect (transitive) dependents. Allowed kinds of dependencies are: `swift_library` (or anything propagating `SwiftInfo`) `cc_library` and `objc_library` (or anything propagating `CcInfo`) Default: `[]`
`copts`	`list of strings`	Additional compiler options that should be passed to `swiftc`. These strings are subject to `$(location ...)` and "Make" variable expansion. Default: `[]`
`defines`	`list of strings`	A list of defines to add to the compilation command line. Note that unlike C-family languages, Swift defines do not have values; they are simply identifiers that are either defined or undefined. So strings in this list should be simple identifiers, not `name=value` pairs. Each string is prepended with `-D` and added to the command line. Unlike `copts`, these flags are added for the target and every target that depends on it, so use this attribute with caution. It is preferred that you add defines directly to `copts`, only using this feature in the rare case that a library needs to propagate a symbol up to those that depend on it. Default: `[]`
`module_name`	`string`	The name of the Swift module being built. If left unspecified, the module name will be computed based on the target's build label, by stripping the leading `//` and replacing `/`, `:`, and other non-identifier characters with underscores. Default: `""`
`package_name`	`string`	The semantic package of the Swift target being built. Targets with the same package_name can access APIs using the 'package' access control modifier in Swift 5.9+. Default: `""`
`plugins`	`list of labels`	A list of `swift_compiler_plugin` targets that should be loaded by the compiler when compiling this module and any modules that directly depend on it. Default: `[]`
`srcs`	`list of labels`	A list of `.swift` source files that will be compiled into the library. Except in very rare circumstances, a Swift source file should only appear in a single `swift_` target. Adding the same source file to multiple `swift_` targets can lead to binary bloat and/or symbol collisions. If specific sources need to be shared by multiple targets, consider factoring them out into their own `swift_library` instead. Default: `[]`
`swiftc_inputs`	`list of labels`	Additional files that are referenced using `$(location ...)` in attributes that support location expansion. Default: `[]`
`additional_linker_inputs`	`list of labels`	List of additional files needed by the linker. These files will be passed to the linker when linking the binary target. Typically, these are linker scripts or other files referenced by `linkopts`. Default: `[]`
`linkopts`	`list of strings`	Additional linker options that should be passed to `clang`. These strings are subject to `$(location ...)` expansion. Default: `[]`
`malloc`	`label`	Override the default dependency on `malloc`. By default, Swift binaries are linked against `@bazel_tools//tools/cpp:malloc"`, which is an empty library and the resulting binary will use libc's `malloc`. This label must refer to a `cc_library` rule. Default: `"@bazel_tools//tools/cpp:malloc"`
`stamp`	`integer`	Enable or disable link stamping; that is, whether to encode build information into the binary. Possible values are: `stamp = 1`: Stamp the build information into the binary. Stamped binaries are only rebuilt when their dependencies change. Use this if there are tests that depend on the build information. `stamp = 0`: Always replace build information by constant values. This gives good build result caching. `stamp = -1`: Embedding of build information is controlled by the `--[no]stamp` flag. Default: `-1`
`env`	`dictionary: String → String`	Specifies additional environment variables to set when the test is executed by `bazel run` or `bazel test`. The values of these environment variables are subject to `$(location)` and "Make variable" substitution. NOTE: The environment variables are not set when you run the target outside of Bazel (for example, by manually executing the binary in `bazel-bin/`). Default: `{}`

swift_compiler_plugin

Compiles and links a Swift compiler plugin (for example, a macro).

A compiler plugin is a standalone executable that minimally implements the
CompilerPlugin protocol from the SwiftCompilerPlugin module in swift-syntax.
As of the time of this writing (Xcode 15.0), a compiler plugin can contain one
or more macros, which can be associated with other Swift targets to perform
syntax-tree-based expansions.

When a swift_compiler_plugin target is listed in the plugins attribute of a
swift_library, it will be loaded by that library and any targets that directly
depend on it. (The plugins attribute also exists on swift_binary,
swift_test, and swift_compiler_plugin itself, to support plugins that are
only used within those targets.)

Compiler plugins also support being built as a library so that they can be
tested. The swift_test rule can contain swift_compiler_plugin targets in its
deps, and the plugin's module can be imported by the test's sources so that
unit tests can be written against the plugin.

Example:

# The actual macro code, using SwiftSyntax
swift_compiler_plugin(
    name = "Macros",
    srcs = glob(["Macros/*.swift"]),
    deps = [
        "@swift-syntax//:SwiftSyntax",
        "@swift-syntax//:SwiftCompilerPlugin",
        "@swift-syntax//:SwiftSyntaxMacros",
    ],
)

# A target testing the macro itself
swift_test(
    name = "MacrosTests",
    srcs = glob(["MacrosTests/*.swift"]),
    deps = [
        ":Macros",
        "@swift-syntax//:SwiftSyntaxMacrosTestSupport",
    ],
)

# The library that defines the macro hook for use in your project
swift_library(
    name = "MacroLibrary",
    srcs = glob(["MacroLibrary/*.swift"]),
    plugins = [":Macros"],
)

# A consumer of the macro library. This doesn't have to be separate from the
# MacroLibrary depending on what makes sense for your project's organization
swift_library(
    name = "MacroConsumer",
    srcs = glob(["Sources/*.swift"]),
    deps = [":MacroLibrary"],
)

Attribute	Type	Description
`*name`	`name`	A unique name for this target.
`data`	`list of labels`	The list of files needed by this target at runtime. Files and targets named in the `data` attribute will appear in the `*.runfiles` area of this target, if it has one. This may include data files needed by a binary or library, or other programs needed by it. Default: `[]`
`deps`	`list of labels`	A list of targets that are dependencies of the target being built, which will be linked into that target. If the Swift toolchain supports implementation-only imports (`private_deps` on `swift_library`), then targets in `deps` are treated as regular (non-implementation-only) imports that are propagated both to their direct and indirect (transitive) dependents. Allowed kinds of dependencies are: `swift_library` (or anything propagating `SwiftInfo`) `cc_library` and `objc_library` (or anything propagating `CcInfo`) Default: `[]`
`copts`	`list of strings`	Additional compiler options that should be passed to `swiftc`. These strings are subject to `$(location ...)` and "Make" variable expansion. Default: `[]`
`defines`	`list of strings`	A list of defines to add to the compilation command line. Note that unlike C-family languages, Swift defines do not have values; they are simply identifiers that are either defined or undefined. So strings in this list should be simple identifiers, not `name=value` pairs. Each string is prepended with `-D` and added to the command line. Unlike `copts`, these flags are added for the target and every target that depends on it, so use this attribute with caution. It is preferred that you add defines directly to `copts`, only using this feature in the rare case that a library needs to propagate a symbol up to those that depend on it. Default: `[]`
`module_name`	`string`	The name of the Swift module being built. If left unspecified, the module name will be computed based on the target's build label, by stripping the leading `//` and replacing `/`, `:`, and other non-identifier characters with underscores. Default: `""`
`package_name`	`string`	The semantic package of the Swift target being built. Targets with the same package_name can access APIs using the 'package' access control modifier in Swift 5.9+. Default: `""`
`plugins`	`list of labels`	A list of `swift_compiler_plugin` targets that should be loaded by the compiler when compiling this module and any modules that directly depend on it. Default: `[]`
`srcs`	`list of labels`	A list of `.swift` source files that will be compiled into the library. Except in very rare circumstances, a Swift source file should only appear in a single `swift_` target. Adding the same source file to multiple `swift_` targets can lead to binary bloat and/or symbol collisions. If specific sources need to be shared by multiple targets, consider factoring them out into their own `swift_library` instead. Default: `[]`
`swiftc_inputs`	`list of labels`	Additional files that are referenced using `$(location ...)` in attributes that support location expansion. Default: `[]`
`additional_linker_inputs`	`list of labels`	List of additional files needed by the linker. These files will be passed to the linker when linking the binary target. Typically, these are linker scripts or other files referenced by `linkopts`. Default: `[]`
`linkopts`	`list of strings`	Additional linker options that should be passed to `clang`. These strings are subject to `$(location ...)` expansion. Default: `[]`
`malloc`	`label`	Override the default dependency on `malloc`. By default, Swift binaries are linked against `@bazel_tools//tools/cpp:malloc"`, which is an empty library and the resulting binary will use libc's `malloc`. This label must refer to a `cc_library` rule. Default: `"@bazel_tools//tools/cpp:malloc"`
`stamp`	`integer`	Enable or disable link stamping; that is, whether to encode build information into the binary. Possible values are: `stamp = 1`: Stamp the build information into the binary. Stamped binaries are only rebuilt when their dependencies change. Use this if there are tests that depend on the build information. `stamp = 0`: Always replace build information by constant values. This gives good build result caching. `stamp = -1`: Embedding of build information is controlled by the `--[no]stamp` flag. Default: `0`

swift_compiler_plugin_import

Allows for a Swift compiler plugin to be loaded from a prebuilt executable or
some other binary-propagating rule, instead of building the plugin from source
using swift_compiler_plugin.

Attribute	Type	Description
`*name`	`name`	A unique name for this target.
`*executable`	`label`	The compiler plugin executable that will be passed to the Swift compiler when compiling any modules that depend on the plugin. This attribute may refer directly to an executable binary or to another rule that produces an executable binary.
`*module_names`	`list of strings`	The list of names of Swift modules in the plugin executable that provide implementations of plugin types, which the compiler uses to look up their implementations.

swift_cross_import_overlay

Declares a cross-import overlay that will be automatically added as a dependency
by the toolchain if its declaring and bystanding modules are both imported.

Since Bazel requires the dependency graph to be explicit, cross-import overlays
do not work correctly when the Swift compiler attempts to import them
automatically when they aren't represented in the graph. Users can explicitly
depend on the cross-import overlay module, but this is unsatisfying because
there is no single import declaration in the source code that indicates what
needs to be depended on.

To address this, the toolchain owner can define a swift_cross_import_overlay
target for each cross-import overlay that they wish to support and set them as
cross_import_overlays on the toolchain. During Swift compilation analysis, the
direct dependencies will be scanned and if any pair of dependencies matches a
cross-import overlay defined by the toolchain, the overlay module will be
automatically injected as a dependency as well.

NOTE: This rule and its associated APIs only exists to support cross-import
overlays already defined by Apple's SDKs. Since cross-import overlays are not
a public feature of the compiler and its design and implementation may change in
the future, this rule is not recommended for other widespread use.

Attribute	Type	Description
`*name`	`name`	A unique name for this target.
`*bystanding_module`	`label`	A label for the target representing the second of the two modules (the other being `declaring_module`) that must be imported for the cross-import overlay modules to be imported. It is completely passive in the cross-import process, having no definition with or other association to either the declaring module or the cross-import modules.
`bystanding_module_name`	`string`	The name of the bystanding module from the target specified by the `bystanding_module` attribute. This is inferred if `bystanding_module` only exports a single direct module; this name must be specified if `bystanding_module` exports more than one. Default: `""`
`*declaring_module`	`label`	A label for the target representing the first of the two modules (the other being `bystanding_module`) that must be imported for the cross-import overlay modules to be imported. This is the module that contains the `.swiftcrossimport` overlay definition that connects it to the bystander and to the overlay modules.
`declaring_module_name`	`string`	The name of the declaring module from the target specified by the `declaring_module` attribute. This is inferred if `declaring_module` only exports a single direct module; this name must be specified if `declaring_module` exports more than one. Default: `""`
`*deps`	`list of labels`	A non-empty list of targets representing modules that should be passed as dependencies when a target depends on both `declaring_module` and `bystanding_module`.
`*swiftoverlay`	`string`	The path to the SDK `.swiftoverlay` file that declares this cross-import.

swift_feature_allowlist

Limits the ability to request or disable certain features to a set of packages
(and possibly subpackages) in the workspace.

A Swift toolchain target can reference any number (zero or more) of
swift_feature_allowlist targets. The features managed by these allowlists may
overlap. For some package P, a feature is allowed to be used by targets in
that package if P matches the packages patterns in all of the allowlists
that manage that feature.

A feature that is not managed by any allowlist is allowed to be used by any
package.

Attribute	Type	Description
`*name`	`name`	A unique name for this target.
`aspect_ids`	`list of strings`	A list of strings representing the identifiers of aspects that are allowed to enable/disable the features in `managed_features`, even when the aspect is applied to packages not covered by the `packages` attribute. Aspect identifiers are each expected to be of the form `<.bzl file label>%<aspect top-level name>` (i.e., the form one would use if invoking it from the command line, as described at https://bazel.build/extending/aspects#invoking_the_aspect_using_the_command_line). Default: `[]`
`managed_features`	`list of strings`	A list of feature strings that are permitted to be specified by the targets in the packages matched by the `packages` attribute or an aspect whose name matches the `aspect_ids` attribute (in any package). This list may include both feature names and/or negations (a name with a leading `-`); a regular feature name means that the matching targets/aspects may explicitly request that the feature be enabled, and a negated feature means that the target may explicitly request that the feature be disabled. For example, `managed_features = ["foo", "-bar"]` means that targets in the allowlist's packages/aspects may request that feature `"foo"` be enabled and that feature `"bar"` be disabled. Default: `[]`
`*packages`	`list of strings`	A list of strings representing packages (possibly recursive) whose targets are allowed to enable/disable the features in `managed_features`. Each package pattern is written in the syntax used by the `package_group` function: `//foo/bar`: Targets in the package `//foo/bar` but not in subpackages. `//foo/bar/...`: Targets in the package `//foo/bar` and any of its subpackages. A leading `-` excludes packages that would otherwise have been included by the patterns in the list. Exclusions always take priority over inclusions; order in the list is irrelevant.

swift_import

Allows for the use of Swift textual module interfaces and/or precompiled Swift
modules as dependencies in other swift_library and swift_binary targets.

To use swift_import targets across Xcode versions and/or OS versions, it is
required to use .swiftinterface files. These can be produced by the pre-built
target if built with:

--features=swift.enable_library_evolution
--features=swift.emit_swiftinterface

If the pre-built target supports .private.swiftinterface files, these can be
used instead of .swiftinterface files in the swiftinterface attribute.

To import pre-built Swift modules that use @_spi when using swiftinterface,
the .private.swiftinterface files are required in order to build any code that
uses the API marked with @_spi.

Attribute	Type	Description
`*name`	`name`	A unique name for this target.
`data`	`list of labels`	The list of files needed by this target at runtime. Files and targets named in the `data` attribute will appear in the `*.runfiles` area of this target, if it has one. This may include data files needed by a binary or library, or other programs needed by it. Default: `[]`
`deps`	`list of labels`	A list of targets that are dependencies of the target being built, which will be linked into that target. If the Swift toolchain supports implementation-only imports (`private_deps` on `swift_library`), then targets in `deps` are treated as regular (non-implementation-only) imports that are propagated both to their direct and indirect (transitive) dependents. Allowed kinds of dependencies are: `swift_library` (or anything propagating `SwiftInfo`) `cc_library` and `objc_library` (or anything propagating `CcInfo`) Default: `[]`
`archives`	`list of labels`	The list of `.a` or `.lo` files provided to Swift targets that depend on this target. Default: `[]`
`*module_name`	`string`	The name of the module represented by this target.
`plugins`	`list of labels`	A list of `swift_compiler_plugin` targets that should be loaded by the compiler when compiling any modules that directly depend on this target. Default: `[]`
`swiftdoc`	`label`	The `.swiftdoc` file provided to Swift targets that depend on this target. Default: `None`
`swiftinterface`	`label`	The `.swiftinterface` file that defines the module interface for this target. May not be specified if `swiftmodule` is specified. Default: `None`
`swiftmodule`	`label`	The `.swiftmodule` file provided to Swift targets that depend on this target. May not be specified if `swiftinterface` is specified. Default: `None`

swift_interop_hint

Defines an aspect hint that associates non-Swift BUILD targets with additional
information required for them to be imported by Swift.

Some build rules, such as objc_library, support interoperability with Swift
simply by depending on them; a module map is generated automatically. This is
for convenience, because the common case is that most objc_library targets
contain code that is compatible (i.e., capable of being imported) by Swift.

For other rules, like cc_library, additional information must be provided to
indicate that a particular target is compatible with Swift. This is done using
the aspect_hints attribute and the swift_interop_hint rule.

Using the automatically derived module name (recommended)

If you want to import a non-Swift, non-Objective-C target into Swift using the
module name that is automatically derived from the BUILD label, there is no need
to declare an instance of swift_interop_hint. A canonical one that requests
module name derivation has been provided in
@rules_swift//swift:auto_module. Simply add it to the aspect_hints of
the target you wish to import:

# //my/project/BUILD
cc_library(
    name = "somelib",
    srcs = ["somelib.c"],
    hdrs = ["somelib.h"],
    aspect_hints = ["@rules_swift//swift:auto_module"],
)

When this cc_library is a dependency of a Swift target, a module map will be
generated for it. In this case, the module's name would be my_project_somelib.

Using an explicit module name

If you need to provide an explicit name for the module (for example, if it is
part of a third-party library that expects to be imported with a specific name),
then you can declare your own swift_interop_hint target to define the name:

# //my/project/BUILD
cc_library(
    name = "somelib",
    srcs = ["somelib.c"],
    hdrs = ["somelib.h"],
    aspect_hints = [":somelib_swift_interop"],
)

swift_interop_hint(
    name = "somelib_swift_interop",
    module_name = "CSomeLib",
)

When this cc_library is a dependency of a Swift target, a module map will be
generated for it with the module name CSomeLib.

Using a custom module map

In rare cases, the automatically generated module map may not be suitable. For
example, a Swift module may depend on a C module that defines specific
submodules, and this is not handled by the Swift build rules. In this case, you
can provide the module map file using the module_map attribute.

When setting the module_map attribute, module_name must also be set to the
name of the desired top-level module; it cannot be omitted.

# //my/project/BUILD
cc_library(
    name = "somelib",
    srcs = ["somelib.c"],
    hdrs = ["somelib.h"],
    aspect_hints = [":somelib_swift_interop"],
)

swift_interop_hint(
    name = "somelib_swift_interop",
    module_map = "module.modulemap",
    module_name = "CSomeLib",
)

Suppressing a module

As mentioned above, objc_library and other Objective-C targets generate
modules by default, without an explicit hint, for convenience. In some
situations, this behavior may not be desirable. For example, an objc_library
might contain only Objective-C++ code in its headers that would not be possible
to import into Swift at all.

When building with implicit modules, this is not typically an issue because the
module map would only be used if Swift code tried to import it (although it does
create useless actions and compiler inputs during the build). When building with
explicit modules, however, Bazel needs to know which targets represent modules
that it can compile and which do not.

In these cases, there is no need to declare an instance of swift_interop_hint.
A canonical one that suppresses module generation has been provided in
@rules_swift//swift:no_module. Simply add it to the aspect_hints of
the target whose module you wish to suppress:

# //my/project/BUILD
objc_library(
    name = "somelib",
    srcs = ["somelib.mm"],
    hdrs = ["somelib.h"],
    aspect_hints = ["@rules_swift//swift:no_module"],
)

When this objc_library is a dependency of a Swift target, no module map or
explicit module will be generated for it, nor will any Swift information from
its transitive dependencies be propagated.

Attribute	Type	Description
`*name`	`name`	A unique name for this target.
`exclude_hdrs`	`list of labels`	A list of header files that should be excluded from the Clang module generated for the target to which this hint is applied. This allows a target to exclude a subset of a library's headers specifically from the Swift module map without removing them from the library completely, which can be useful if some headers are not Swift-compatible but are still needed by other sources in the library or by non-Swift dependents. This attribute may only be specified if a custom `module_map` is not provided. Setting both attributes is an error. Default: `[]`
`module_map`	`label`	An optional custom `.modulemap` file that defines the Clang module for the headers in the target to which this hint is applied. If this attribute is omitted, a module map will be automatically generated based on the headers in the hinted target. If this attribute is provided, then `module_name` must also be provided and match the name of the desired top-level module in the `.modulemap` file. (A single `.modulemap` file may define multiple top-level modules.) Default: `None`
`module_name`	`string`	The name that will be used to import the hinted module into Swift. If left unspecified, the module name will be computed based on the hinted target's build label, by stripping the leading `//` and replacing `/`, `:`, and other non-identifier characters with underscores. Default: `""`
`suppressed`	`boolean`	If `True`, the hinted target should suppress any module that it would otherwise generate. Default: `False`

swift_library

Compiles and links Swift code into a static library and Swift module.

Attribute	Type	Description
`*name`	`name`	A unique name for this target.
`data`	`list of labels`	The list of files needed by this target at runtime. Files and targets named in the `data` attribute will appear in the `*.runfiles` area of this target, if it has one. This may include data files needed by a binary or library, or other programs needed by it. Default: `[]`
`deps`	`list of labels`	A list of targets that are dependencies of the target being built, which will be linked into that target. If the Swift toolchain supports implementation-only imports (`private_deps` on `swift_library`), then targets in `deps` are treated as regular (non-implementation-only) imports that are propagated both to their direct and indirect (transitive) dependents. Allowed kinds of dependencies are: `swift_library` (or anything propagating `SwiftInfo`) `cc_library` and `objc_library` (or anything propagating `CcInfo`) Default: `[]`
`copts`	`list of strings`	Additional compiler options that should be passed to `swiftc`. These strings are subject to `$(location ...)` and "Make" variable expansion. Default: `[]`
`defines`	`list of strings`	A list of defines to add to the compilation command line. Note that unlike C-family languages, Swift defines do not have values; they are simply identifiers that are either defined or undefined. So strings in this list should be simple identifiers, not `name=value` pairs. Each string is prepended with `-D` and added to the command line. Unlike `copts`, these flags are added for the target and every target that depends on it, so use this attribute with caution. It is preferred that you add defines directly to `copts`, only using this feature in the rare case that a library needs to propagate a symbol up to those that depend on it. Default: `[]`
`module_name`	`string`	The name of the Swift module being built. If left unspecified, the module name will be computed based on the target's build label, by stripping the leading `//` and replacing `/`, `:`, and other non-identifier characters with underscores. Default: `""`
`package_name`	`string`	The semantic package of the Swift target being built. Targets with the same package_name can access APIs using the 'package' access control modifier in Swift 5.9+. Default: `""`
`plugins`	`list of labels`	A list of `swift_compiler_plugin` targets that should be loaded by the compiler when compiling this module and any modules that directly depend on it. Default: `[]`
`*srcs`	`list of labels`	A list of `.swift` source files that will be compiled into the library. Except in very rare circumstances, a Swift source file should only appear in a single `swift_` target. Adding the same source file to multiple `swift_` targets can lead to binary bloat and/or symbol collisions. If specific sources need to be shared by multiple targets, consider factoring them out into their own `swift_library` instead.
`swiftc_inputs`	`list of labels`	Additional files that are referenced using `$(location ...)` in attributes that support location expansion. Default: `[]`
`always_include_developer_search_paths`	`boolean`	If `True`, the developer framework search paths will be added to the compilation command. This enables a Swift module to access `XCTest` without having to mark the target as `testonly = True`. Default: `False`
`library_evolution`	`boolean`	Indicates whether the Swift code should be compiled with library evolution mode enabled. This attribute should be used to compile a module that will be distributed as part of a client-facing (non-implementation-only) module in a library or framework that will be distributed for use outside of the Bazel build graph. Setting this to true will compile the module with the `-library-evolution` flag and emit a `.swiftinterface` file as one of the compilation outputs. Default: `False`
`alwayslink`	`boolean`	If `False`, any binary that depends (directly or indirectly) on this Swift module will only link in all the object files for the files listed in `srcs` when there is a direct symbol reference. Swift protocol conformances don't create linker references. Likewise, if the Swift code has Objective-C classes/methods, their usage does not always result in linker references. "All the object files" for this module is also somewhat fuzzy. Unlike C, C++, and Objective-C, where each source file results in a `.o` file; for Swift the number of .o files depends on the compiler options (`-wmo`/`-whole-module-optimization`, `-num-threads`). That makes relying on linker reference more fragile, and any individual .swift file in `srcs` may/may not get picked up based on the linker references to other files that happen to get batched into a single `.o` by the compiler options used. Swift Package Manager always passes the individual `.o` files to the linker instead of using intermediate static libraries, so it effectively is the same as `alwayslink = True`. Note that by default, this value will default to True. But if the swift.enable_embedded feature is on, this value will be automatically overridden to False, as the swift features that cause -force_load to be required (such as reflection) are not available in that mode. Default: `True`
`generated_header_name`	`string`	The name of the generated Objective-C interface header. This name must end with a `.h` extension and cannot contain any path separators. If this attribute is not specified, then the default behavior is to name the header `${target_name}-Swift.h`. This attribute is ignored if the toolchain does not support generating headers. Default: `""`
`generates_header`	`boolean`	If True, an Objective-C header will be generated for this target, in the same build package where the target is defined. By default, the name of the header is `${target_name}-Swift.h`; this can be changed using the `generated_header_name` attribute. Targets should only set this attribute to True if they export Objective-C APIs. A header generated for a target that does not export Objective-C APIs will be effectively empty (except for a large amount of prologue and epilogue code) and this is generally wasteful because the extra file needs to be propagated in the build graph and, when explicit modules are enabled, extra actions must be executed to compile the Objective-C module for the generated header. Default: `False`
`linkopts`	`list of strings`	Additional linker options that should be passed to the linker for the binary that depends on this target. These strings are subject to `$(location ...)` and "Make" variable expansion. Default: `[]`
`linkstatic`	`boolean`	If True, the Swift module will be built for static linking. This will make all interfaces internal to the module that is being linked against and will inform the consuming module that the objects will be locally available (which may potentially avoid a PLT relocation). Set to `False` to build a `.so` or `.dll`. Default: `True`
`private_deps`	`list of labels`	A list of targets that are implementation-only dependencies of the target being built. Libraries/linker flags from these dependencies will be propagated to dependent for linking, but artifacts/flags required for compilation (such as .swiftmodule files, C headers, and search paths) will not be propagated. Allowed kinds of dependencies are: `swift_library` (or anything propagating `SwiftInfo`) `cc_library` and `objc_library` (or anything propagating `CcInfo`) Default: `[]`

swift_library_group

Groups Swift compatible libraries (e.g. swift_library and objc_library).
The target can be used anywhere a swift_library can be used. It behaves
similar to source-less {cc,obj}_library targets.

A new module isn't created for this target, you need to import the grouped
libraries directly.

Attribute Type Description

*name

name

A unique name for this target.

deps

list of labels

A list of targets that should be included in the group.
Allowed kinds of dependencies are:

swift_library (or anything propagating SwiftInfo)
cc_library and objc_library (or anything propagating CcInfo)

Default: []

swift_module_mapping

Defines a set of
module aliases
that will be passed to the Swift compiler.

This rule defines a mapping from original module names to aliased names. This is
useful if you are building a library or framework for external use and want to
ensure that dependencies do not conflict with other versions of the same library
that another framework or the client may use.

To use this feature, first define a swift_module_mapping target that lists the
aliases you need:

# //some/package/BUILD

swift_library(
    name = "Utils",
    srcs = [...],
    module_name = "Utils",
)

swift_library(
    name = "Framework",
    srcs = [...],
    module_name = "Framework",
    deps = [":Utils"],
)

swift_module_mapping(
    name = "mapping",
    aliases = {
        "Utils": "GameUtils",
    },
)

Then, pass the label of that target to Bazel using the
--@rules_swift//swift:module_mapping build flag:

bazel build //some/package:Framework \
    --@rules_swift//swift:module_mapping=//some/package:mapping

When Utils is compiled, it will be given the module name GameUtils instead.
Then, when Framework is compiled, it will import GameUtils anywhere that the
source asked to import Utils.

Attribute Type Description

*name

name

A unique name for this target.

*aliases

dictionary: String → String

A dictionary that remaps the names of Swift modules.

Each key in the dictionary is the name of a module as it is written in source
code. The corresponding value is the replacement module name to use when
compiling it and/or any modules that depend on it.

swift_module_mapping_test

Validates that a swift_module_mapping target covers all the modules in the
transitive closure of a list of dependencies.

If you are building a static library or framework for external distribution and
you are using swift_module_mapping to rename some of the modules used by your
implementation, this rule will detect if any of your dependencies have taken on
a new dependency that you need to add to the mapping (otherwise, its symbols
would leak into your library with their original names).

When executed, this test will collect the names of all Swift modules in the
transitive closure of deps. System modules and modules whose names are listed
in the exclude attribute are omitted. Then, the test will fail if any of the
remaining modules collected are not present in the aliases of the
swift_module_mapping target specified by the mapping attribute.

Attribute	Type	Description
`*name`	`name`	A unique name for this target.
`exclude`	`list of strings`	A list of module names that may be in the transitive closure of `deps` but are not required to be covered by `mapping`. Default: `[]`
`*mapping`	`label`	The label of a `swift_module_mapping` target against which the transitive closure of `deps` will be validated.
`*deps`	`list of labels`	A list of Swift targets whose transitive closure will be validated against the `swift_module_mapping` target specified by `mapping`.

swift_overlay

A Swift overlay that sits on top of a C/Objective-C library, allowing an author
of a C/Objective-C library to create additional Swift-specific APIs that are
automatically available when a Swift target depends on their C/Objective-C
library.

The Swift overlay will only be compiled when other Swift targets depend on the
original library that uses the overlay; non-Swift clients depending on the
original library will not cause the Swift overlay code to be built or linked.
This is done to retain optimium build performance and binary size for non-Swift
clients. For this reason, swift_overlay is not a general purpose mechanism
for creating mixed-language modules; swift_overlay does not support generation
of an Objective-C header.

The swift_overlay rule does not perform any compilation of its own. Instead,
it must be placed in the aspect_hints attribute of another rule such as
objc_library or cc_library. For example,

objc_library(
    name = "MyModule",
    srcs = ["MyModule.m"],
    hdrs = ["MyModule.h"],
    aspect_hints = [":MyModule_overlay"],
    deps = [...],
)

swift_overlay(
    name = "MyModule_overlay",
    srcs = ["MyModule.swift"],
    deps = [...],
)

When some other Swift target, such as a swift_library, depends on MyModule,
the Swift code in MyModule_overlay will be compiled into the same module.
Therefore, when that library imports MyModule, it will see the APIs from the
objc_library and the swift_overlay as a single combined module.

When writing a Swift overlay, the Swift code must do a re-exporting import of
its own module in order to access the C/Objective-C APIs; they are not available
automatically. Continuing the example above, any Swift sources that want to use
or extend the API from the C/Objective-C side of the module would need to write
the following:

@_exported import MyModule

The swift_overlay rule supports all the same attributes as swift_library,
except for the following:

module_name is not supported because the overlay inherits the same module
name as the target it is attached to.
generates_header and generated_header_name are not supported because it
is assumed that the overlay is pure Swift code that does not export any APIs
that would be of interest to C/Objective-C clients.

Aside from its module name and its underlying C/Objective-C module dependency,
swift_overlay does not inherit anything else from its associated target. If
the swift_overlay imports any modules other than its C/Objective-C side, the
overlay target must explicitly depend on them as well. This means that an
overlay can have a different set of dependencies than the underlying module, if
desired.

There is a tight coupling between a Swift overlay and the C/Objective-C module
to which it is being applied, so a specific swift_overlay target should only
be referenced by the aspect_hints of a single objc_library or cc_library
target. Referencing a swift_overlay from multiple targets' aspect_hints is
almost always an anti-pattern.

Attribute	Type	Description
`*name`	`name`	A unique name for this target.
`deps`	`list of labels`	A list of targets that are dependencies of the target being built, which will be linked into that target. If the Swift toolchain supports implementation-only imports (`private_deps` on `swift_library`), then targets in `deps` are treated as regular (non-implementation-only) imports that are propagated both to their direct and indirect (transitive) dependents. Allowed kinds of dependencies are: `swift_library` (or anything propagating `SwiftInfo`) `cc_library` and `objc_library` (or anything propagating `CcInfo`) Default: `[]`
`copts`	`list of strings`	Additional compiler options that should be passed to `swiftc`. These strings are subject to `$(location ...)` and "Make" variable expansion. Default: `[]`
`defines`	`list of strings`	A list of defines to add to the compilation command line. Note that unlike C-family languages, Swift defines do not have values; they are simply identifiers that are either defined or undefined. So strings in this list should be simple identifiers, not `name=value` pairs. Each string is prepended with `-D` and added to the command line. Unlike `copts`, these flags are added for the target and every target that depends on it, so use this attribute with caution. It is preferred that you add defines directly to `copts`, only using this feature in the rare case that a library needs to propagate a symbol up to those that depend on it. Default: `[]`
`package_name`	`string`	The semantic package of the Swift target being built. Targets with the same package_name can access APIs using the 'package' access control modifier in Swift 5.9+. Default: `""`
`plugins`	`list of labels`	A list of `swift_compiler_plugin` targets that should be loaded by the compiler when compiling this module and any modules that directly depend on it. Default: `[]`
`*srcs`	`list of labels`	A list of `.swift` source files that will be compiled into the library. Except in very rare circumstances, a Swift source file should only appear in a single `swift_` target. Adding the same source file to multiple `swift_` targets can lead to binary bloat and/or symbol collisions. If specific sources need to be shared by multiple targets, consider factoring them out into their own `swift_library` instead.
`swiftc_inputs`	`list of labels`	Additional files that are referenced using `$(location ...)` in attributes that support location expansion. Default: `[]`
`always_include_developer_search_paths`	`boolean`	If `True`, the developer framework search paths will be added to the compilation command. This enables a Swift module to access `XCTest` without having to mark the target as `testonly = True`. Default: `False`
`library_evolution`	`boolean`	Indicates whether the Swift code should be compiled with library evolution mode enabled. This attribute should be used to compile a module that will be distributed as part of a client-facing (non-implementation-only) module in a library or framework that will be distributed for use outside of the Bazel build graph. Setting this to true will compile the module with the `-library-evolution` flag and emit a `.swiftinterface` file as one of the compilation outputs. Default: `False`
`alwayslink`	`boolean`	If `False`, any binary that depends (directly or indirectly) on this Swift module will only link in all the object files for the files listed in `srcs` when there is a direct symbol reference. Swift protocol conformances don't create linker references. Likewise, if the Swift code has Objective-C classes/methods, their usage does not always result in linker references. "All the object files" for this module is also somewhat fuzzy. Unlike C, C++, and Objective-C, where each source file results in a `.o` file; for Swift the number of .o files depends on the compiler options (`-wmo`/`-whole-module-optimization`, `-num-threads`). That makes relying on linker reference more fragile, and any individual .swift file in `srcs` may/may not get picked up based on the linker references to other files that happen to get batched into a single `.o` by the compiler options used. Swift Package Manager always passes the individual `.o` files to the linker instead of using intermediate static libraries, so it effectively is the same as `alwayslink = True`. Note that by default, this value will default to True. But if the swift.enable_embedded feature is on, this value will be automatically overridden to False, as the swift features that cause -force_load to be required (such as reflection) are not available in that mode. Default: `True`
`linkopts`	`list of strings`	Additional linker options that should be passed to the linker for the binary that depends on this target. These strings are subject to `$(location ...)` and "Make" variable expansion. Default: `[]`
`linkstatic`	`boolean`	If True, the Swift module will be built for static linking. This will make all interfaces internal to the module that is being linked against and will inform the consuming module that the objects will be locally available (which may potentially avoid a PLT relocation). Set to `False` to build a `.so` or `.dll`. Default: `True`
`private_deps`	`list of labels`	A list of targets that are implementation-only dependencies of the target being built. Libraries/linker flags from these dependencies will be propagated to dependent for linking, but artifacts/flags required for compilation (such as .swiftmodule files, C headers, and search paths) will not be propagated. Allowed kinds of dependencies are: `swift_library` (or anything propagating `SwiftInfo`) `cc_library` and `objc_library` (or anything propagating `CcInfo`) Default: `[]`

swift_package_configuration

A compilation configuration to apply to the Swift targets in a set of packages.

A Swift toolchain target can reference any number (zero or more) of
swift_package_configuration targets. When the compilation action for a target
is being configured, those package configurations will be applied if the
target's label is included by the package specifications in the configuration.

Attribute Type Description

*name

name

A unique name for this target.

configured_features

list of strings

A list of feature strings that will be applied by default to targets in the
packages matched by the packages attribute, as if they had been specified by
the package(features = ...) rule in the BUILD file.

This list may include both feature names and/or negations (a name with a leading
-); a regular feature name means that the targets in the matching packages
will have the feature enabled, and a negated feature means that the target will
have the feature disabled.

For example, configured_features = ["foo", "-bar"] means that targets in the
configuration's packages will have the feature "foo" enabled by default and
the feature "bar" disabled by default.

Default: []

*packages

list of strings

A list of strings representing packages (possibly recursive) whose targets will
have this package configuration applied. Each package pattern is written in the
syntax used by the package_group function:

//foo/bar: Targets in the package //foo/bar but not in subpackages.
//foo/bar/...: Targets in the package //foo/bar and any of its
subpackages.
A leading - excludes packages that would otherwise have been included by
the patterns in the list.

Exclusions always take priority over inclusions; order in the list is
irrelevant.

swift_proto_compiler

Attribute	Type	Description
`*name`	`name`	A unique name for this target.
`bundled_proto_paths`	`list of strings`	List of proto paths for which to skip generation because they're built into the modules imported by the generated Swift proto code, e.g., SwiftProtobuf. Default: `["google/protobuf/any.proto", "google/protobuf/api.proto", "google/protobuf/descriptor.proto", "google/protobuf/duration.proto", "google/protobuf/empty.proto", "google/protobuf/field_mask.proto", "google/protobuf/source_context.proto", "google/protobuf/struct.proto", "google/protobuf/timestamp.proto", "google/protobuf/type.proto", "google/protobuf/wrappers.proto"]`
`deps`	`list of labels`	List of targets providing SwiftInfo and CcInfo. Added as implicit dependencies for any swift_proto_library using this compiler. Typically, these are Well Known Types and proto runtime libraries. Default: `[]`
`protoc`	`label`	Default: `None`
`*plugin`	`label`	A proto compiler plugin executable binary. For example: "//tools/protoc_wrapper:protoc-gen-grpc-swift" "//tools/protoc_wrapper:ProtoCompilerPlugin"
`*plugin_name`	`string`	Name of the proto compiler plugin passed to protoc. For example: `protoc --plugin=protoc-gen-NAME=path/to/plugin/binary` This name will be used to prefix the option and output directory arguments. E.g.: `protoc --plugin=protoc-gen-NAME=path/to/mybinary --NAME_out=OUT_DIR --NAME_opt=Visibility=Public` See the protobuf API reference for more information.
`*plugin_option_allowlist`	`list of strings`	Allowlist of options allowed by the plugin. This is used to filter out any irrelevant plugin options passed down to the compiler from the library, which is especially useful when using multiple plugins in combination like GRPC and SwiftProtobuf.
`*plugin_options`	`dictionary: String → String`	Dictionary of plugin options passed to the plugin. These are prefixed with the plugin_name + "_opt". E.g.: `plugin_name = "swift" plugin_options = { "Visibility": "Public", "FileNaming": "FullPath", }` Would be passed to protoc as: `protoc --plugin=protoc-gen-NAME=path/to/plugin/binary --NAME_opt=Visibility=Public --NAME_opt=FileNaming=FullPath`
`*suffixes`	`list of strings`	Suffix used for Swift files generated by the plugin from protos. E.g. `foo.proto => foo.pb.swift foo_service.proto => foo.grpc.swift` Each compiler target should configure this based on the suffix applied to the generated files.

swift_proto_library

Generates a Swift static library from one or more targets producing ProtoInfo.

load("@protobuf//bazel:proto_library.bzl", "proto_library")
load("//proto:swift_proto_library.bzl", "swift_proto_library")

proto_library(
    name = "foo",
    srcs = ["foo.proto"],
)

swift_proto_library(
    name = "foo_swift",
    protos = [":foo"],
)

If your protos depend on protos from other targets, add dependencies between the
swift_proto_library targets which mirror the dependencies between the proto targets.

load("@protobuf//bazel:proto_library.bzl", "proto_library")
load("//proto:swift_proto_library.bzl", "swift_proto_library")

proto_library(
    name = "bar",
    srcs = ["bar.proto"],
    deps = [":foo"],
)

swift_proto_library(
    name = "bar_swift",
    protos = [":bar"],
    deps = [":foo_swift"],
)

Attribute	Type	Description
`*name`	`name`	A unique name for this target.
`data`	`list of labels`	The list of files needed by this target at runtime. Files and targets named in the `data` attribute will appear in the `*.runfiles` area of this target, if it has one. This may include data files needed by a binary or library, or other programs needed by it. Default: `[]`
`deps`	`list of labels`	A list of targets that are dependencies of the target being built, which will be linked into that target. If the Swift toolchain supports implementation-only imports (`private_deps` on `swift_library`), then targets in `deps` are treated as regular (non-implementation-only) imports that are propagated both to their direct and indirect (transitive) dependents. Allowed kinds of dependencies are: `swift_library` (or anything propagating `SwiftInfo`) `cc_library` and `objc_library` (or anything propagating `CcInfo`) Default: `[]`
`copts`	`list of strings`	Additional compiler options that should be passed to `swiftc`. These strings are subject to `$(location ...)` and "Make" variable expansion. Default: `[]`
`defines`	`list of strings`	A list of defines to add to the compilation command line. Note that unlike C-family languages, Swift defines do not have values; they are simply identifiers that are either defined or undefined. So strings in this list should be simple identifiers, not `name=value` pairs. Each string is prepended with `-D` and added to the command line. Unlike `copts`, these flags are added for the target and every target that depends on it, so use this attribute with caution. It is preferred that you add defines directly to `copts`, only using this feature in the rare case that a library needs to propagate a symbol up to those that depend on it. Default: `[]`
`module_name`	`string`	The name of the Swift module being built. If left unspecified, the module name will be computed based on the target's build label, by stripping the leading `//` and replacing `/`, `:`, and other non-identifier characters with underscores. Default: `""`
`package_name`	`string`	The semantic package of the Swift target being built. Targets with the same package_name can access APIs using the 'package' access control modifier in Swift 5.9+. Default: `""`
`plugins`	`list of labels`	A list of `swift_compiler_plugin` targets that should be loaded by the compiler when compiling this module and any modules that directly depend on it. Default: `[]`
`srcs`	`list of labels`	A list of `.swift` source files that will be compiled into the library. Except in very rare circumstances, a Swift source file should only appear in a single `swift_` target. Adding the same source file to multiple `swift_` targets can lead to binary bloat and/or symbol collisions. If specific sources need to be shared by multiple targets, consider factoring them out into their own `swift_library` instead. Default: `[]`
`swiftc_inputs`	`list of labels`	Additional files that are referenced using `$(location ...)` in attributes that support location expansion. Default: `[]`
`always_include_developer_search_paths`	`boolean`	If `True`, the developer framework search paths will be added to the compilation command. This enables a Swift module to access `XCTest` without having to mark the target as `testonly = True`. Default: `False`
`library_evolution`	`boolean`	Indicates whether the Swift code should be compiled with library evolution mode enabled. This attribute should be used to compile a module that will be distributed as part of a client-facing (non-implementation-only) module in a library or framework that will be distributed for use outside of the Bazel build graph. Setting this to true will compile the module with the `-library-evolution` flag and emit a `.swiftinterface` file as one of the compilation outputs. Default: `False`
`alwayslink`	`boolean`	If `False`, any binary that depends (directly or indirectly) on this Swift module will only link in all the object files for the files listed in `srcs` when there is a direct symbol reference. Swift protocol conformances don't create linker references. Likewise, if the Swift code has Objective-C classes/methods, their usage does not always result in linker references. "All the object files" for this module is also somewhat fuzzy. Unlike C, C++, and Objective-C, where each source file results in a `.o` file; for Swift the number of .o files depends on the compiler options (`-wmo`/`-whole-module-optimization`, `-num-threads`). That makes relying on linker reference more fragile, and any individual .swift file in `srcs` may/may not get picked up based on the linker references to other files that happen to get batched into a single `.o` by the compiler options used. Swift Package Manager always passes the individual `.o` files to the linker instead of using intermediate static libraries, so it effectively is the same as `alwayslink = True`. Note that by default, this value will default to True. But if the swift.enable_embedded feature is on, this value will be automatically overridden to False, as the swift features that cause -force_load to be required (such as reflection) are not available in that mode. Default: `True`
`generated_header_name`	`string`	The name of the generated Objective-C interface header. This name must end with a `.h` extension and cannot contain any path separators. If this attribute is not specified, then the default behavior is to name the header `${target_name}-Swift.h`. This attribute is ignored if the toolchain does not support generating headers. Default: `""`
`generates_header`	`boolean`	If True, an Objective-C header will be generated for this target, in the same build package where the target is defined. By default, the name of the header is `${target_name}-Swift.h`; this can be changed using the `generated_header_name` attribute. Targets should only set this attribute to True if they export Objective-C APIs. A header generated for a target that does not export Objective-C APIs will be effectively empty (except for a large amount of prologue and epilogue code) and this is generally wasteful because the extra file needs to be propagated in the build graph and, when explicit modules are enabled, extra actions must be executed to compile the Objective-C module for the generated header. Default: `False`
`linkopts`	`list of strings`	Additional linker options that should be passed to the linker for the binary that depends on this target. These strings are subject to `$(location ...)` and "Make" variable expansion. Default: `[]`
`linkstatic`	`boolean`	If True, the Swift module will be built for static linking. This will make all interfaces internal to the module that is being linked against and will inform the consuming module that the objects will be locally available (which may potentially avoid a PLT relocation). Set to `False` to build a `.so` or `.dll`. Default: `True`
`protos`	`list of labels`	A list of `proto_library` targets (or targets producing `ProtoInfo`), from which the Swift source files should be generated. Default: `[]`
`compilers`	`list of labels`	One or more `swift_proto_compiler` targets (or targets producing `SwiftProtoCompilerInfo`), from which the Swift protos will be generated. Default: `["@rules_swift//proto/compilers:swift_proto"]`
`additional_compiler_deps`	`list of labels`	List of additional dependencies required by the generated Swift code at compile time, whose SwiftProtoInfo will be ignored. Allowed kinds of dependencies are: `swift_library` (or anything propagating `SwiftInfo`) `cc_library` and `objc_library` (or anything propagating `CcInfo`) Default: `[]`
`additional_compiler_info`	`dictionary: String → String`	Dictionary of additional information passed to the compiler targets. See the documentation of the respective compiler rules for more information on which fields are accepted and how they are used. Default: `{}`

swift_proto_library_group

Generates a collection of Swift static library from a target producing ProtoInfo and its dependencies.

This rule is intended to facilitate migration from the deprecated swift proto library rules to the new ones.
Unlike swift_proto_library which is a drop-in-replacement for swift_library,
this rule uses an aspect over the direct proto library dependency and its transitive dependencies,
compiling each into a swift static library.

For example, in the following targets, the proto_library_group_swift_proto target only depends on
package_2_proto target, and this transitively depends on package_1_proto.

When used as a dependency from a swift_library or swift_binary target,
two modules generated from these proto library targets are visible.

Because these are derived from the proto library targets via an aspect, though,
you cannot customize many of the attributes including the swift proto compiler targets or
the module names. The module names are derived from the proto library names.

In this case, the module names are:

import examples_xplatform_proto_library_group_package_1_package_1_proto
import examples_xplatform_proto_library_group_package_2_package_2_proto

For this reason, we would encourage new consumers of the proto rules to use
swift_proto_library when possible.

proto_library(
    name = "package_1_proto",
    srcs = glob(["*.proto"]),
    visibility = ["//visibility:public"],
)

...

proto_library(
    name = "package_2_proto",
    srcs = glob(["*.proto"]),
    visibility = ["//visibility:public"],
    deps = ["//examples/xplatform/proto_library_group/package_1:package_1_proto"],
)

...

swift_proto_library_group(
    name = "proto_library_group_swift_proto",
    proto = "//examples/xplatform/proto_library_group/package_2:package_2_proto",
)

...

swift_binary(
    name = "proto_library_group_example",
    srcs = ["main.swift"],
    deps = [
        ":proto_library_group_swift_proto",
    ],
)

Attribute	Type	Description
`*name`	`name`	A unique name for this target.
`compiler`	`label`	A `swift_proto_compiler` target (or target producing `SwiftProtoCompilerInfo`), from which the Swift protos will be generated. Default: `"@rules_swift//proto/compilers:swift_proto"`
`*proto`	`label`	Exactly one `proto_library` target (or target producing `ProtoInfo`), from which the Swift source files should be generated.

swift_test

Compiles and links Swift code into an executable test target.

XCTest Test Discovery

By default, this rule performs test discovery that finds tests written with
the XCTest framework and executes them automatically, without the user
providing their own main entry point.

On Apple platforms, XCTest-style tests are automatically discovered and
executed using the Objective-C runtime. To provide the same behavior on Linux,
the swift_test rule performs its own scan for XCTest-style tests. In other
words, you can write a single swift_test target that executes the same tests
on either Linux or Apple platforms.

There are two approaches that one can take to write a swift_test that supports
test discovery:

Preferred approach: Write a swift_test target whose srcs contain
your tests. In this mode, only these sources will be scanned for tests;
direct dependencies will not be scanned.
Write a swift_test target with no srcs. In this mode, all direct
dependencies of the target will be scanned for tests; indirect dependencies
will not be scanned. This approach is useful if you want to share tests
with an Apple-specific test target like ios_unit_test.

See the documentation of the discover_tests attribute for more information
about how this behavior affects the rule's outputs.

Test Bundles

The swift_test rule always produces a standard executable binary. This is true
even when targeting macOS, where the typical practice is to use a Mach-O bundle
binary. However, when targeting macOS, the executable binary is still generated
inside a bundle-like directory structure: {name}.xctest/Contents/MacOS/{name}.
This allows tests to still work if they contain logic that looks for the path to
their bundle.

Test Filtering

swift_test supports Bazel's --test_filter flag on all platforms (i.e., Apple
and Linux), which can be used to run only a subset of tests. The test filter can
be a test name of the form ClassName/MethodName or a regular expression that
matches names of that form.

For example,

--test_filter='ArrayTests/testAppend' would only run the test method
testAppend in the ArrayTests class.
--test_filter='ArrayTests/test(App.*|Ins.*)' would run all test methods
starting with testApp or testIns in the ArrayTests class.

Xcode Integration

If integrating with Xcode, the relative paths in test binaries can prevent the
Issue navigator from working for test failures. To work around this, you can
have the paths made absolute via swizzling by enabling the
"apple.swizzle_absolute_xcttestsourcelocation" feature. You'll also need to
set the BUILD_WORKSPACE_DIRECTORY environment variable in your scheme to the
root of your workspace (i.e. $(SRCROOT)).

Attribute	Type	Description
`*name`	`name`	A unique name for this target.
`data`	`list of labels`	The list of files needed by this target at runtime. Files and targets named in the `data` attribute will appear in the `*.runfiles` area of this target, if it has one. This may include data files needed by a binary or library, or other programs needed by it. Default: `[]`
`deps`	`list of labels`	A list of targets that are dependencies of the target being built, which will be linked into that target. If the Swift toolchain supports implementation-only imports (`private_deps` on `swift_library`), then targets in `deps` are treated as regular (non-implementation-only) imports that are propagated both to their direct and indirect (transitive) dependents. Allowed kinds of dependencies are: `swift_library` (or anything propagating `SwiftInfo`) `cc_library` and `objc_library` (or anything propagating `CcInfo`) Default: `[]`
`copts`	`list of strings`	Additional compiler options that should be passed to `swiftc`. These strings are subject to `$(location ...)` and "Make" variable expansion. Default: `[]`
`defines`	`list of strings`	A list of defines to add to the compilation command line. Note that unlike C-family languages, Swift defines do not have values; they are simply identifiers that are either defined or undefined. So strings in this list should be simple identifiers, not `name=value` pairs. Each string is prepended with `-D` and added to the command line. Unlike `copts`, these flags are added for the target and every target that depends on it, so use this attribute with caution. It is preferred that you add defines directly to `copts`, only using this feature in the rare case that a library needs to propagate a symbol up to those that depend on it. Default: `[]`
`module_name`	`string`	The name of the Swift module being built. If left unspecified, the module name will be computed based on the target's build label, by stripping the leading `//` and replacing `/`, `:`, and other non-identifier characters with underscores. Default: `""`
`package_name`	`string`	The semantic package of the Swift target being built. Targets with the same package_name can access APIs using the 'package' access control modifier in Swift 5.9+. Default: `""`
`plugins`	`list of labels`	A list of `swift_compiler_plugin` targets that should be loaded by the compiler when compiling this module and any modules that directly depend on it. Default: `[]`
`srcs`	`list of labels`	A list of `.swift` source files that will be compiled into the library. Except in very rare circumstances, a Swift source file should only appear in a single `swift_` target. Adding the same source file to multiple `swift_` targets can lead to binary bloat and/or symbol collisions. If specific sources need to be shared by multiple targets, consider factoring them out into their own `swift_library` instead. Default: `[]`
`swiftc_inputs`	`list of labels`	Additional files that are referenced using `$(location ...)` in attributes that support location expansion. Default: `[]`
`additional_linker_inputs`	`list of labels`	List of additional files needed by the linker. These files will be passed to the linker when linking the binary target. Typically, these are linker scripts or other files referenced by `linkopts`. Default: `[]`
`linkopts`	`list of strings`	Additional linker options that should be passed to `clang`. These strings are subject to `$(location ...)` expansion. Default: `[]`
`malloc`	`label`	Override the default dependency on `malloc`. By default, Swift binaries are linked against `@bazel_tools//tools/cpp:malloc"`, which is an empty library and the resulting binary will use libc's `malloc`. This label must refer to a `cc_library` rule. Default: `"@bazel_tools//tools/cpp:malloc"`
`stamp`	`integer`	Enable or disable link stamping; that is, whether to encode build information into the binary. Possible values are: `stamp = 1`: Stamp the build information into the binary. Stamped binaries are only rebuilt when their dependencies change. Use this if there are tests that depend on the build information. `stamp = 0`: Always replace build information by constant values. This gives good build result caching. `stamp = -1`: Embedding of build information is controlled by the `--[no]stamp` flag. Default: `0`
`env`	`dictionary: String → String`	Dictionary of environment variables that should be set during the test execution. Default: `{}`
`discover_tests`	`boolean`	Determines whether or not tests are automatically discovered in the binary. The default value is `True`. Tests are discovered in a platform-specific manner. On Apple platforms, they are found using the XCTest framework's `XCTestSuite.default` accessor, which uses the Objective-C runtime to dynamically discover tests. On non-Apple platforms, discovery uses symbol graphs generated from dependencies to find classes and methods written in XCTest's style. If tests are discovered, then you should not provide your own `main` entry point in the `swift_test` binary; the test runtime provides the entry point for you. If you set this attribute to `False`, then you are responsible for providing your own `main`. This allows you to write tests that use a framework other than Apple's `XCTest`. The only requirement of such a test is that it terminate with a zero exit code for success or a non-zero exit code for failure. Default: `True`
`env_inherit`	`list of strings`	Specifies additional environment variables to inherit from the external environment when the test is executed by `bazel test`. Default: `[]`

universal_swift_compiler_plugin

Wraps an existing swift_compiler_plugin target to produce a universal binary.

This is useful to allow sharing of caches between Intel and Apple Silicon Macs
at the cost of building everything twice.

Example:

# The actual macro code, using SwiftSyntax, as usual.
swift_compiler_plugin(
    name = "Macros",
    srcs = glob(["Macros/*.swift"]),
    deps = [
        "@swift-syntax//:SwiftSyntax",
        "@swift-syntax//:SwiftCompilerPlugin",
        "@swift-syntax//:SwiftSyntaxMacros",
    ],
)

# Wrap your compiler plugin in this universal shim.
universal_swift_compiler_plugin(
    name = "Macros.universal",
    plugin = ":Macros",
)

# The library that defines the macro hook for use in your project, this
# references the universal_swift_compiler_plugin.
swift_library(
    name = "MacroLibrary",
    srcs = glob(["MacroLibrary/*.swift"]),
    plugins = [":Macros.universal"],
)

Attribute	Type	Description
`*name`	`name`	A unique name for this target.
`*plugin`	`label`	Target to generate a 'fat' binary from.

@rules_swift@rules_swift//swift:providers.bzl

Defines providers propagated by the Swift BUILD rules and related utilities.

This file must be kept lightweight and not load any other .bzl files that may
update frequently (e.g., other files in rules_swift). This ensures that changes
to the rule implementations do not unnecessarily cause reanalysis impacting
users who just load these providers to inspect and/or repropagate them.

Functions & Macros

create_swift_module_context

Creates a value containing Clang/Swift module artifacts of a dependency.

It is possible for both clang and swift to be present; this is the case
for Swift modules that generate an Objective-C header, where the Swift
module artifacts are propagated in the swift context and the generated
header and module map are propagated in the clang context.

Though rare, it is also permitted for both the clang and swift arguments
to be None. One example of how this can be used is to model system
dependencies (like Apple SDK frameworks) that are implicitly available as
part of a non-hermetic SDK (Xcode) but do not propagate any artifacts of
their own. This would only apply in a build using implicit modules, however;
when using explicit modules, one would propagate the module artifacts
explicitly. But allowing for the empty case keeps the build graph consistent
if switching between the two modes is necessary, since it will not change
the set of transitive module names that are propagated by dependencies
(which other build rules may want to depend on for their own analysis).

Parameters

`*name`	The name of the module.
`clang`	A value returned by `create_clang_module_inputs` that contains artifacts related to Clang modules, such as a module map or precompiled module. This may be `None` if the module is a pure Swift module with no generated Objective-C interface. Default: `None`
`const_gather_protocols`	A list of protocol names from which constant values should be extracted from source code that takes this module as a direct dependency. Default: `[]`
`compilation_context`	A value returned from `swift_common.create_compilation_context` that contains the context needed to compile the module being built. This may be `None` if the module wasn't compiled from sources. Default: `None`
`is_framework`	Indictates whether the module is a framework module. The default value is `False`. Default: `False`
`is_system`	Indicates whether the module is a system module. The default value is `False`. System modules differ slightly from non-system modules in the way that they are passed to the compiler. For example, non-system modules have their Clang module maps passed to the compiler in both implicit and explicit module builds. System modules, on the other hand, do not have their module maps passed to the compiler in implicit module builds because there is currently no way to indicate that modules declared in a file passed via `-fmodule-map-file` should be treated as system modules even if they aren't declared with the `[system]` attribute, and some system modules may not build cleanly with respect to warnings otherwise. Therefore, it is assumed that any module with `is_system == True` must be able to be found using import search paths in order for implicit module builds to succeed. Default: `False`
`swift`	A value returned by `create_swift_module_inputs` that contains artifacts related to Swift modules, such as the `.swiftmodule`, `.swiftdoc`, and/or `.swiftinterface` files emitted by the compiler. This may be `None` if the module is a pure C/Objective-C module. Default: `None`

create_clang_module_inputs

Creates a value representing a Clang module used as a Swift dependency.

Parameters

`*compilation_context`	A `CcCompilationContext` that contains the header files and other context (such as include paths, preprocessor defines, and so forth) needed to compile this module as an explicit module.
`*module_map`	The text module map file that defines this module. This argument may be specified as a `File` or as a `string`; in the latter case, it is assumed to be the path to a file that cannot be provided as an action input because it is outside the workspace (for example, the module map for a module from an Xcode SDK).
`precompiled_module`	A `File` representing the precompiled module (`.pcm` file) if one was emitted for the module. This may be `None` if no explicit module was built for the module; in that case, targets that depend on the module will fall back to the text module map and headers. Default: `None`
`strict_includes`	A `depset` of strings representing additional Clang include paths that should be passed to the compiler when this module is a direct dependency of the module being compiled. May be `None`. This field only exists to support a specific legacy use case and should otherwise not be used, as it is fundamentally incompatible with Swift's import model. Default: `None`

create_swift_module_inputs

Creates a value representing a Swift module use as a Swift dependency.

Parameters

`ast_files`	A list of `File`s output from the `DUMP_AST` action. Default: `[]`
`const_protocols_to_gather`	A list of protocol names from which constant values should be extracted from source code that takes this module as a direct dependency. Default: `[]`
`defines`	A list of defines that will be provided as `copts` to targets that depend on this module. If omitted, the empty list will be used. Default: `[]`
`generated_header`	A `File` representing the Swift generated header. Default: `None`
`indexstore`	A `File` representing the directory that contains the index store data generated by the compiler if the `"swift.index_while_building"` feature is enabled, otherwise this will be `None`. Default: `None`
`original_module_name`	The original name of the module if it was changed by a module mapping; otherwise, `None`. Default: `None`
`plugins`	A list of `SwiftCompilerPluginInfo` providers representing compiler plugins that are required by this module and should be loaded by the compiler when this module is directly depended on. Default: `[]`
`private_swiftinterface`	The `.private.swiftinterface` file emitted by the compiler for this module. May be `None` if no private module interface file was emitted. Default: `None`
`*swiftdoc`	The `.swiftdoc` file emitted by the compiler for this module.
`swiftinterface`	The `.swiftinterface` file emitted by the compiler for this module. May be `None` if no module interface file was emitted. Default: `None`
`*swiftmodule`	The `.swiftmodule` file emitted by the compiler for this module, or a string path to a system-provided prebuilt `.swiftmodule` file.
`swiftsourceinfo`	The `.swiftsourceinfo` file emitted by the compiler for this module. May be `None` if no source info file was emitted. Default: `None`

Providers

SwiftBinaryInfo

Information about a binary target's module.
swift_binary and swift_compiler_plugin propagate this provider that wraps
CcInfo and SwiftInfo providers, instead of propagating them directly, so
that swift_test targets can depend on those binaries and test their modules
(similar to what Swift Package Manager allows) without allowing any
swift_library to depend on an arbitrary binary.

Fields

cc_info

A CcInfo provider containing the binary's code compiled as a static library,
which is suitable for linking into a swift_test so that unit tests can be
written against it.
Notably, this CcInfo's linking context does not contain the linker flags
used to alias the main entry point function, because the purpose of this
provider is to allow it to be linked into another binary that would provide its
own entry point instead.

swift_info

A SwiftInfo provider representing the Swift module created by compiling the
target. This is used specifically by swift_test to allow test code to depend
on the binary's module without making it possible for arbitrary libraries or
binaries to depend on other binaries.

SwiftFeatureAllowlistInfo

Describes a set of features and the packages and aspects that are allowed to
request or disable them.

This provider is an internal implementation detail of the rules; users should
not rely on it or assume that its structure is stable.

Fields

`allowlist_label`	A string containing the label of the `swift_feature_allowlist` target that created this provider.
`aspect_ids`	A list of strings representing identifiers of aspects that are allowed to request or disable a feature managed by the allowlist, even when the target the aspect is being applied to does not match `package_specs`.
`managed_features`	A list of strings representing feature names or their negations that packages in the `packages` list are allowed to explicitly request or disable.
`package_specs`	A list of `struct` values representing package specifications that indicate which packages (possibly recursive) can request or disable a feature managed by the allowlist.

SwiftInfo

Contains information about the compiled artifacts of a Swift module.

This provider has a custom initializer that will merge the transitive modules of
a list of SwiftInfo providers, rather than a separate "merge" function. The
correct signature when creating a new SwiftInfo provider is the following:

SwiftInfo(
    direct_swift_infos,
    modules,
    swift_infos,
)

where the arguments are:

direct_swift_infos: A list of SwiftInfo providers from dependencies
whose direct modules should be treated as direct modules in the resulting
provider, in addition to their transitive modules being merged.
modules: A list of values (as returned by create_swift_module_context)
that represent Clang and/or Swift module artifacts that are direct outputs
of the target being built.
swift_infos: A list of SwiftInfo providers from dependencies whose
transitive modules should be merged into the resulting provider.

When reading an existing SwiftInfo provider, it has the two fields described
below.

Fields

`direct_modules`	`List` of values returned from `create_swift_module_context`. The modules (both Swift and C/Objective-C) emitted by the library that propagated this provider.
`transitive_modules`	`Depset` of values returned from `create_swift_module_context`. The transitive modules (both Swift and C/Objective-C) emitted by the library that propagated this provider and all of its dependencies.

SwiftOverlayInfo

Contains additional artifacts from the Swift overlay for a C/Objective-C module
that also need to be propagated to clients of the module for it to work
properly.

Fields

linking_context

CcLinkingContext. A linking context that contain object files, linker flags,
and additional linker inputs for Swift code that was compiled as an overlay for
a C/Objective-C target.

SwiftPackageConfigurationInfo

Describes a compiler configuration that is applied by default to targets in a
specific set of packages.

This provider is an internal implementation detail of the rules; users should
not rely on it or assume that its structure is stable.

Fields

`disabled_features`	`List` of strings. Features that will be disabled by default on targets in the packages listed in this package configuration.
`enabled_features`	`List` of strings. Features that will be enabled by default on targets in the packages listed in this package configuration.
`package_specs`	A list of `struct` values representing package specifications that indicate the set of packages (possibly recursive) to which this configuration is applied.

SwiftProtoCompilerInfo

Provides information needed to generate Swift code from ProtoInfo providers

Fields

`bundled_proto_paths`	List of proto paths for which to skip generation because they're built into the modules imported by the generated Swift proto code, e.g., SwiftProtobuf.
`compile`	A function which compiles Swift source files from `ProtoInfo` providers. Args: label: The label of the target for which the Swift files are being generated. actions: The actions object used to declare the files to be generated and the actions that generate them. swift_proto_compiler_info: This `SwiftProtoCompilerInfo` provider. additional_compiler_info: Additional information passed from the target target to the compiler. proto_infos: The list of `ProtoInfo` providers to compile. module_mappings: The module_mappings field of the `SwiftProtoInfo` for the target. Returns: A list of .swift Files generated by the compiler.
`compiler_deps`	List of targets providing SwiftInfo and CcInfo. These are added as dependencies to the swift compile action of the swift_proto_library. Typically these are proto runtime libraries. Well Known Types should be added as dependencies of the swift_proto_library targets as needed to avoid compiling them unnecessarily.
`internal`	Opaque struct passing information from the compiler target to the compile function.

SwiftProtoInfo

Propagates Swift-specific information about a proto_library.

Fields

`module_name`	The name of the Swift module compiled from the `swift_proto_library` which produced this provider.
`module_mappings`	`list` of `struct`s. Each struct contains `module_name` and `proto_file_paths` fields that denote the transitive mappings from `.proto` files to Swift modules. This allows messages that reference messages in other libraries to import those modules in generated code.
`direct_pbswift_files`	`list` of `File`s. The Swift source files (e.g. `.pb.swift`) generated from the `ProtoInfo` providers of the direct proto dependencies of the `swift_proto_library` target.
`pbswift_files`	`depset` of `File`s. The Swift source files (e.g. `.pb.swift`) generated from the `ProtoInfo` providers of the direct and transitive transitive proto dependencies of the `swift_proto_library` target.

SwiftSymbolGraphInfo

Propagates extracted symbol graph files from Swift modules.

Fields

direct_symbol_graphs

List of structs representing the symbol graphs extracted from the target
that propagated this provider. This list will be empty if propagated by a
non-Swift target (although its transitive_symbol_graphs may be non-empty if it
has Swift dependencies).

Each struct has the following fields:

module_name: A string denoting the name of the Swift module.
symbol_graph_dir: A directory-type File containing one or more
.symbols.json files representing the symbol graph(s) for the module.

transitive_symbol_graphs

Depset of structs representing the symbol graphs extracted from the target
that propagated this provider and all of its Swift dependencies. Each struct
has the same fields as documented in direct_symbol_graphs.

SwiftSynthesizedInterfaceInfo

Propagates synthesized Swift interfaces for modules.

Fields

direct_modules

List of structs representing the synthesized interfaces for the modules in
the target that propagated this provider. This list will be empty if propagated
by a target that does not contain any modules that Swift can synthesize an
interface for (i.e., C, or Swift itself), but its transitive_modules may be
non-empty if it has dependencies for which interfaces can be synthesized.

Each struct has the following fields:

module_name: A string denoting the name of the module whose interface is
synthesized.
synthesized_interface: A File containing the synthesized interface.

transitive_modules

Depset of structs representing the synthesized interfaces for the modules in
the target that propagated this provider and all of its dependencies. Each
struct has the same fields as documented in direct_modules.

SwiftToolchainInfo

Propagates information about a Swift toolchain to compilation and linking rules
that use the toolchain.

Fields

`action_configs`	This field is an internal implementation detail of the build rules.
`cc_language`	The `language` that should be passed to `cc_common` APIs that take it as an argument.
`cc_toolchain_info`	The `cc_common.CcToolchainInfo` provider from the Bazel C++ toolchain that this Swift toolchain depends on.
`clang_implicit_deps_providers`	A `struct` with the following fields, which represent providers from targets that should be added as implicit dependencies of any precompiled explicit C/Objective-C modules: `cc_infos`: A list of `CcInfo` providers from targets specified as the toolchain's implicit dependencies. `swift_infos`: A list of `SwiftInfo` providers from targets specified as the toolchain's implicit dependencies. For ease of use, this field is never `None`; it will always be a valid `struct` containing the fields described above, even if those lists are empty.
`const_protocols_to_gather`	`File`. A JSON file specifying a list of protocols for extraction of conformances' const values.
`cross_import_overlays`	A list of `SwiftCrossImportOverlayInfo` providers whose `SwiftInfo` providers will be automatically injected into the dependencies of Swift compilations if their declaring module and bystanding module are both already declared as dependencies.
`debug_outputs_provider`	An optional function that provides toolchain-specific logic around the handling of additional debug outputs for `swift_binary` and `swift_test` targets. If specified, this function must take the following keyword arguments: `ctx`: The rule context of the calling binary or test rule. It must return a `struct` with the following fields: `additional_outputs`: Additional outputs expected from the linking action. `variables_extension`: A dictionary of additional crosstool variables to pass to the linking action.
`developer_dirs`	A list of `structs` containing the following fields: `developer_path_label`: A `string` representing the type of developer path. `path`: A `string` representing the path to the developer framework.
`entry_point_linkopts_provider`	A function that returns flags that should be passed to the linker to control the name of the entry point of a linked binary for rules that customize their entry point. This function must take the following keyword arguments: `entry_point_name`: The name of the entry point function, as was passed to the Swift compiler using the `-entry-point-function-name` flag. It must return a `struct` with the following fields: `linkopts`: A list of strings that will be passed as additional linker flags when linking a binary with a custom entry point.
`feature_allowlists`	A list of `SwiftFeatureAllowlistInfo` providers that allow or prohibit packages from requesting or disabling features.
`generated_header_module_implicit_deps_providers`	A `struct` with the following fields, which are providers from targets that should be treated as compile-time inputs to actions that precompile the explicit module for the generated Objective-C header of a Swift module: `cc_infos`: A list of `CcInfo` providers from targets specified as the toolchain's implicit dependencies. `swift_infos`: A list of `SwiftInfo` providers from targets specified as the toolchain's implicit dependencies. This is used to provide modular dependencies for the fixed inclusions (Darwin, Foundation) that are unconditionally emitted in those files. For ease of use, this field is never `None`; it will always be a valid `struct` containing the fields described above, even if those lists are empty.
`implicit_deps_providers`	A `struct` with the following fields, which represent providers from targets that should be added as implicit dependencies of any Swift compilation or linking target (but not to precompiled explicit C/Objective-C modules): `cc_infos`: A list of `CcInfo` providers from targets specified as the toolchain's implicit dependencies. `swift_infos`: A list of `SwiftInfo` providers from targets specified as the toolchain's implicit dependencies. For ease of use, this field is never `None`; it will always be a valid `struct` containing the fields described above, even if those lists are empty.
`module_aliases`	A `SwiftModuleAliasesInfo` provider that defines the module aliases to use during compilation.
`package_configurations`	A list of `SwiftPackageConfigurationInfo` providers that specify additional compilation configuration options that are applied to targets on a per-package basis.
`requested_features`	`List` of `string`s. Features that should be implicitly enabled by default for targets built using this toolchain, unless overridden by the user by listing their negation in the `features` attribute of a target/package or in the `--features` command line flag. These features determine various compilation and debugging behaviors of the Swift build rules, and they are also passed to the C++ APIs used when linking (so features defined in CROSSTOOL may be used here).
`root_dir`	`String`. The workspace-relative root directory of the toolchain.
`runtime`	`List` of `File`s. Files required at runtime by compiled executables. They will be added to the input root at execution time.
`swift_worker`	`File`. The executable representing the worker executable used to invoke the compiler and other Swift tools (for both incremental and non-incremental compiles).
`system_modules`	A `struct` with the following fields, which represent providers from targets that should be added as implicit dependencies of any compilation or linking target: `cc_infos`: A list of `CcInfo` providers from targets specified as the toolchain's implicit dependencies. `swift_infos`: A list of `SwiftInfo` providers from targets specified as the toolchain's implicit dependencies. For ease of use, this field is never `None`; it will always be a valid `struct` containing the fields described above, even if those lists are empty.
`implicit_system_modules`	A `struct` with in the same shape as `system_modules` for the system modules that every Swift compilation implicitly requires.
`test_configuration`	`Struct` containing the following fields: `binary_name`: A template string used to compute the name of the output binary for `swift_test` rules. Any occurrences of the string `"{name}"` will be substituted by the name of the target. `env`: A `dict` of environment variables to be set when running tests that were built with this toolchain. `execution_requirements`: A `dict` of execution requirements for tests that were built with this toolchain. `objc_test_discovery`: A Boolean value indicating whether test targets should discover tests dynamically using the Objective-C runtime. `test_linking_contexts`: A list of `CcLinkingContext`s that provide additional flags to use when linking test binaries. This is used, for example, with Xcode-based toolchains to ensure that the `xctest` helper and coverage tools are found in the correct developer directory when running tests.
`tool_configs`	This field is an internal implementation detail of the build rules.
`unsupported_features`	`List` of `string`s. Features that should be implicitly disabled by default for targets built using this toolchain, unless overridden by the user by listing them in the `features` attribute of a target/package or in the `--features` command line flag. These features determine various compilation and debugging behaviors of the Swift build rules, and they are also passed to the C++ APIs used when linking (so features defined in CROSSTOOL may be used here).

SwiftToolsInfo

Propagates information about Swift toolchain tools that can be specified as
labels to pull them into the input root.

This provider allows users to specify Swift toolchain executables as explicit
dependencies, ensuring they are available in the execution environment.

Fields

`swift_driver`	`File`. The Swift driver executable that orchestrates compilation and linking operations. This is the main entry point for invoking the Swift compiler toolchain.
`swift_autolink_extract`	`File`. The executable that extracts autolink information from object files. This tool is used to determine which libraries need to be linked based on import statements in Swift code.
`swift_symbolgraph_extract`	`File`. The executable that extracts symbol graph information from Swift modules. This tool generates structured data about APIs, which can be used for documentation generation and other tooling purposes.
`additional_inputs`	`List` of `File`s. Additional files to add to the action input root when calling these tools.

SwiftClangModuleAspectInfo

A "marker provider" (i.e., it has no fields) that is always returned when
swift_clang_module_aspect is applied to a target.

This provider exists because swift_clang_module_aspect cannot advertise that
it returns SwiftInfo (since some code paths do not). Users who want to ensure
aspect ordering via the required_aspect_providers parameter to their own
aspect function can require this provider instead, which
swift_clang_module_aspect does advertise.