0.11.1

• This release is tested with Bazel 0.27
• The swift_common.run_toolchain{_shell_,_swift_,_}action functions have been removed. (d11785b)

Please use the rules_swift.0.11.1.tar.gz release asset from your Bazel WORKSPACE.

SHA-256 digest: 96a86afcbdab215f8363e65a10cf023b752e90b23abf02272c4fc668fcb70311

Complete list of changes

0.11.0

• This release is tested with Bazel 0.26.
• On Linux, the Swift toolchain can now autoconfigure itself to detect which features are supported by the version of the compiler in use. (a7f4adb)

Thanks to the following contributors:

• Danny Weinberg (@FuegoFro): 01c5d85
• Dave Lee (@kastiglione): b4c87bf, 37dd0ef
• Keith Smiley (@keith): 5161cb8

Please use the rules_swift.0.11.0.tar.gz release asset from your Bazel WORKSPACE.

SHA-256 digest: 245290b9c01950db0903bcb6575b358f8f8cfc3bbd36a1c72566e4608a701dbc

Complete list of changes

0.10.1

• This release is tested with Bazel 0.25.
• Introduce swift_common.compile and remove swift_common.compile_as_{library,objects}. (606d50b, 4f69fc1)
• The direct_libraries, direct_linkopts, transitive_additional_inputs, transitive_libraries, and transitive_linkopts fields of SwiftInfo have been removed. This information is now propagated using linking contexts in CcInfo providers. (9e60959)
• The SwiftClangModuleInfo provider has been deprecated. Headers and include search paths can be obtained from CcInfo's compilation context. Module maps are propagated in SwiftInfo.transitive_modulemaps. (6fcd64b)
• On macOS hosts, you can use a custom toolchain installed in /Library/Developer/Toolchains by passing --define=SWIFT_CUSTOM_TOOLCHAIN=<toolchain id> to Bazel, where <toolchain id> is the bundle identifier of the toolchain. (4fa465e)
  • A tool has been added to dump the toolchain identifiers of any custom toolchains currently installed: bazel run @build_bazel_rules_swift//tools/dump_toolchains. (1aec8de)

Thanks to the following contributors:

• Keith Smiley (@keith): 735dc0f, cc6a709, 4fa465e, fba8785, 1aec8de, 746fda1

Please use the rules_swift.0.10.1.tar.gz release asset from your Bazel WORKSPACE.

SHA-256 digest: fef40f8afc331ae4b63da5603538134444f005e5ca7762112b0629334602c845

Complete list of changes

0.9.0

• This release is tested with Bazel 0.24.1
• The allow_testing, compilation_mode, configuration, objc_fragment, and swift_fragment arguments have been removed from the swift_common.{compile_as_objects,compile_as_library,swiftc_command_line_and_inputs} functions. (ecd0250)
• The swift_grpc_library rule has been added, which can be used to generate Swift code for gRPC clients/servers. Necessary dependencies (gRPC and gRPC-Swift) are automatically added to the workspace. (9034f69)
• Incremental compilation is now supported by passing the --strategy=SwiftCompile=worker flag to Bazel. (637e3f1)
• The compile_options field of the SwiftInfo provider has been removed. The SwiftBinaryInfo provider has been removed. (b73e06d)
• swift_common.merge_swift_info_providers is now named swift_common.merge_swift_infos and takes a list of SwiftInfo providers instead of a list of targets. swift_common.build_swift_info is now named swift_common.create_swift_info and only takes direct arguments and no longer merges transitive info from dependencies. (ef84822)
• Like cc_{binary,test}, swift_{binary,test} now supports a malloc attribute that lets the user substitute an alternate malloc implementation to be linked into the binary. (5a9cd5d)
• When building with Xcode 10.2 (Swift 5.0) or higher, the compiler now passes -debug-prefix-map to the compiler to remap the working directory to ".", removing absolute source paths from the generated debug info. (23389cc)

Thanks to the following contributors:

• Andrew (@chronal-xnor): 6503509
• Keith Smiley (@keith): 1c2f34c, 1a8bd0e, 0ae94bd

Please use the rules_swift.0.9.0.tar.gz release asset from your Bazel WORKSPACE.

SHA-256 digest: 9efe9699e9765e6b4a5e063e4a08f6b163cccaf0443f775d935baf5c3cd6ed0e

Complete list of changes

0.8.0

• This release is tested with Bazel 0.24.
• -simulator is now added to the target triple passed to swiftc (e.g., "-target x86_64-apple-ios10.3-simulator") by the Xcode toolchain when targeting simulator platforms. (73c2508) Thanks @kastiglione!
• The Xcode toolchain now supports dynamically linking to Swift runtimes distributed with the OS (which is the case on macOS 10.14.4 and higher). (d0f1415)
• The allow_testing parameter to swift_common.compile_as_{library,objects} is now deprecated. To control testability of code compiled with these APIs, you should now set or unset the "swift.enable_testing" feature in your feature configuration. (62b3b4c)
• The objc_fragment and swift_fragment arguments to swift_common compilation APIs are now deprecated. (957cdae)
• The feature_configuration argument is now required for the compile_as_objects, compile_as_library, and swiftc_command_line_and_inputs methods in swift_common. (fb38185)

Thanks to the following contributors:

• Dave Lee (@kastiglione): 73c2508, 13acad9
• Keith Smiley (@keith): b22ce2b

Please use the rules_swift.0.8.0.tar.gz release asset from your Bazel WORKSPACE.

SHA-256 digest: 31aad005a9c4e56b256125844ad05eb27c88303502d74138186f9083479f93a6

Complete list of changes

0.7.0

• This release is tested with Bazel 0.23.0.

• swift_library now lists the Objective-C bridging header as one of its output files.

• The cc_libs and module_link_name attributes have been removed from the Swift rules. If you need to create a static library that contains both Swift and C++ code, have the swift_library depend on the cc_library and then use another rule, such as a genrule, to combine the archives.

  To replace the behavior of the module_link_name attribute, pass the -module-link-name <name> flags directly in the target's copts. This change no longer affects the name of the output library; it is the responsibility of the user to ensure that the .a file that is output by the rule matches the link name embedded in the module. This allows the link name to refer to an archive emitted by a different rule, such as one that merges static archives as described above.

• Feature-related APIs in swift_common have changed slightly. The get_{disabled,enabled}_features methods have been removed, and is_enabled has been added. Also, the Swift feature configuration now embeds a C++ feature configuration (accessible by calling swift_common.cc_feature_configuration) for users who need to call C++ APIs with a feature configuration compatible with the Swift toolchain's underlying C++ toolchain.

• Uses of the legacy "cc" provider have been migrated to the new CcInfo provider.

• Uses of the legacy "instrumented_files" provider have been migrated to the new InstrumentedFilesInfo provider.

• Information in SwiftInfo providers is no longer lost when passing through a non-Swift target (such as objc_library). In some cases, build graphs could be constructed that caused upstream Swift compilations to not be passed the .swiftmodule files they needed to perform type lookups.

Full list of changes between 0.6.0 and 0.7.0.

0.6.0

• This release is tested with Bazel 0.21.0.
• Incompatible change: The resources and structured_resources of swift_library have been removed. Replace them as follows:
  • Files and labels referenced in resources can be placed directly in the library's data attribute.
  • Files and labels referenced in structured_resources should be moved to the structured_resources of a new apple_resource_group target (defined in rules_apple) and that target should be placed in the library's data attribute.

0.5.0

• This release is tested with Bazel 0.20.0.
• Support linking prebuilt framework dependencies (objc_framework and the new apple_framework_import rule in rules_apple) into swift_{binary,test} targets.
• Allow Objective-C rules to depend on swift_import targets.
• Add alwayslink support to swift_{binary,test}.
• Add -pie flag when linking on Linux.
• Add descriptive progress messages to most actions.
• Add dependency on bazelbuild/apple_support.

0.4.0

• This release is tested with Bazel 0.19.0.
• Minor debugging improvements.
• Support batch mode compilation for Xcode 10 or higher (macOS only at this time).
• Propagate simple defines between Swift and Objective-C targets.
• Ensure that transitive headers are available when a swift_library depends on a cc_library, and that their include paths are correct.
• A number of compatibility and cleanup fixes for more recent Bazel versions (thanks @keith and @kastiglione!)

0.3.1

• Get linker options from the C++ toolchain for Xcode builds when possible to resolve issues when linking some Apple targets (e.g., test binaries and their bundle loaders).