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.