Merge branch 'master' into codyv/add-missing-swift-toolchain-parameter

.bcr/metadata.template.json

@@ -20,6 +20,11 @@
             "email": "t@thi.im",
             "github": "thii",
             "name": "Thi Doãn"
+        },
+        {
+            "email": "heyluispadron@gmail.com",
+            "github": "luispadron",
+            "name": "Luis Padron"
         }
     ],
     "repository": [

doc/proto_migration.md

@@ -1,7 +1,7 @@
 # Overview
 
 This document aims to provide context to future contributors on why we decided to rewrite
-the `swift_proto_library` and `swift_grpc_library` rules into the new 
+the `swift_proto_library` and `swift_grpc_library` rules into the new
 `swift_proto_library` and `swift_proto_library_group` rules,
 as well as a guide for consumers of the deprecated rules to migrate to the new rules.
 
@@ -12,14 +12,14 @@ On this page:
 ## Why rewrite?
 
 The new `swift_proto_library` rule was created to address several issues with the old
-`swift_proto_library` and `swift_grpc_library` rules which would be difficult if not impossible 
+`swift_proto_library` and `swift_grpc_library` rules which would be difficult if not impossible
 to fix while maintaining full backwards compatibility.
 
 ### 1. The Swift Protoc Gen Aspect
 
 Firstly, the old `swift_proto_library` rule used the `swift_protoc_gen_aspect` aspect
 which traversed its direct `proto_library` dependencies and their transitive graph of `proto_library` dependencies,
-and compiled all of these into swift modules. 
+and compiled all of these into swift modules.
 
 This meant that a single `swift_proto_library` target could generate and and compile swift source files
 for *all* of the `proto_library` targets in potentially a very large dependency graph,
@@ -37,7 +37,7 @@ consumers had to import the generated service swift proto module with:
 import examples_xplatform_deprecated_grpc_echo_server_services_swift
 ```
 
-But with the new `swift_proto_library` rule, 
+But with the new `swift_proto_library` rule,
 they can assign an arbitrary module name to the target and import it with:
 
 ```
@@ -74,7 +74,7 @@ The new swift_proto_library rule is completely configurable in terms of:
 - the proto compiler plugin target(s)
 - the swift compile-time dependency target(s)
 
-This is accomplished with a new `swift_proto_compiler` rule 
+This is accomplished with a new `swift_proto_compiler` rule
 which is passed as an attribute to the new `swift_proto_library` rule.
 
 The `swift_proto_compiler` rule represents the combination of a protoc binary,
@@ -97,8 +97,8 @@ This is how the analagous `go_proto_library` works as well.
 ## How to Migrate
 
 NOTE: If you required the capability of the the deprecated `swift_proto_library`
-to generate the protos transitively for multiple `proto_library` targets from a single `swift_proto_library` target, 
-you will need to to use the `swift_proto_library_group` rule. 
+to generate the protos transitively for multiple `proto_library` targets from a single `swift_proto_library` target,
+you will need to to use the `swift_proto_library_group` rule.
 See the relevant section below for more information.
 
 ## 1. Swift Proto Library
@@ -151,12 +151,12 @@ swift_proto_library(
 )
 ```
 
-Note that you must declare deps between the new `swift_proto_library` targets 
-parallel to those between the `proto_library` targets, and that the autogenerated Swift module names 
+Note that you must declare deps between the new `swift_proto_library` targets
+parallel to those between the `proto_library` targets, and that the autogenerated Swift module names
 of the new targets are derived from the target labels of the `swift_proto_library` targets,
 not the `proto_library` targets as they were before.
 
-If you wish, you may set the `module_name` attribute on the new `swift_proto_library` targets 
+If you wish, you may set the `module_name` attribute on the new `swift_proto_library` targets
 as you would any other `swift_library` target.
 
 ## 2. Swift GRPC Library
@@ -206,13 +206,19 @@ These can be migrated to the following new `swift_proto_library` targets:
 ```
 swift_proto_library(
     name = "service_server_swift_proto",
-    compilers = ["@build_bazel_rules_swift//proto/compilers:swift_server_proto"],
+    compilers = [
+        "@build_bazel_rules_swift//proto/compilers:swift_proto",
+        "@build_bazel_rules_swift//proto/compilers:swift_server_proto",
+    ],
     protos = [":service_proto"],
 )
 
 swift_proto_library(
     name = "service_client_swift_proto",
-    compilers = ["@build_bazel_rules_swift//proto/compilers:swift_client_proto"],
+    compilers = [
+        "@build_bazel_rules_swift//proto/compilers:swift_client_proto",
+        "@build_bazel_rules_swift//proto/compilers:swift_proto",
+    ],
     protos = [":service_proto"],
 )
 
@@ -229,15 +235,15 @@ swift_proto_library(
 )
 ```
 
-Note here that we don't need the intermediate `swift_proto_library` target, 
+Note here that we don't need the intermediate `swift_proto_library` target,
 and that we must pass a `swift_proto_compiler` target via the compilers attribute
 which is configured with a `grpc-swift` protoc plugin.
 
 Also note that the `client_stubs` flavor uses the `swift_test_client_proto` grpc compiler
 and requires additional plugin options and compiler dependencies.
 
 This configuration was added to ensure continuity of rule capabilities,
-but when possible we recommend migrating off of these targets. 
+but when possible we recommend migrating off of these targets.
 This is because TestClient protoc plugin option was deprecated with Swift 5.6,
 as the test clients do not conform to Sendable.
 This capability may be removed in a future major version update.
@@ -250,8 +256,8 @@ To aid consumers of the old rules in their migration to the new rules,
 we introduced the `swift_proto_library_group` rule which has an aspect similar to the old rule,
 while still allowing for pluggable swift proto compilers.
 
-One drawback of the aspect approach that is still present here is the inability 
-to configure the module names or other attributes of the generated modules 
+One drawback of the aspect approach that is still present here is the inability
+to configure the module names or other attributes of the generated modules
 because they must be derived directly from the `proto_library` targets.
 
 Specific usecases for this rule include:
@@ -307,13 +313,13 @@ we will add their answers here as a reference.
 
 Yes, the new rule does not enforce any specific mapping of protos or proto packages to swift modules.
 You can compile each proto into a separate swift module, group protos into modules based on packages,
-or just compile all of your protos into one large module. 
+or just compile all of your protos into one large module.
 
 ### Can I use a completely custom protobuf compiler?
 
-Yes, you can use an arbitrary non-protoc Swift protobuf compiler by implementing your own rule 
+Yes, you can use an arbitrary non-protoc Swift protobuf compiler by implementing your own rule
 which provides `SwiftProtoCompilerInfo`, and passing this to the `swift_proto_library` target's
-`compilers` attribute. 
+`compilers` attribute.
 
 The only real requirement is that it has a function wich accepts a list of `ProtoInfo` providers,
 and produces a list Swift source files from these which the `swift_proto_library` rule compiles.