We here address the following warnings:
WARNING: /Users/dws/src/grpc-dws/src/compiler/BUILD:87:18: target 'grpc_cpp_plugin' is both a rule and a file; please choose another name for the rule
WARNING: /Users/dws/src/grpc-dws/src/compiler/BUILD:93:18: target 'grpc_csharp_plugin' is both a rule and a file; please choose another name for the rule
WARNING: /Users/dws/src/grpc-dws/src/compiler/BUILD:99:18: target 'grpc_node_plugin' is both a rule and a file; please choose another name for the rule
WARNING: /Users/dws/src/grpc-dws/src/compiler/BUILD:105:18: target 'grpc_objective_c_plugin' is both a rule and a file; please choose another name for the rule
WARNING: /Users/dws/src/grpc-dws/src/compiler/BUILD:111:18: target 'grpc_php_plugin' is both a rule and a file; please choose another name for the rule
WARNING: /Users/dws/src/grpc-dws/src/compiler/BUILD:117:18: target 'grpc_python_plugin' is both a rule and a file; please choose another name for the rule
WARNING: /Users/dws/src/grpc-dws/src/compiler/BUILD:123:18: target 'grpc_ruby_plugin' is both a rule and a file; please choose another name for the rule
that come from asking Bazel to build the following:
@com_github_grpc_grpc//src/compiler:grpc_cpp_plugin
@com_github_grpc_grpc//src/compiler:grpc_csharp_plugin
@com_github_grpc_grpc//src/compiler:grpc_node_plugin
@com_github_grpc_grpc//src/compiler:grpc_objective_c_plugin
@com_github_grpc_grpc//src/compiler:grpc_php_plugin
@com_github_grpc_grpc//src/compiler:grpc_python_plugin
@com_github_grpc_grpc//src/compiler:grpc_ruby_plugin
The macro grpc_proto_plugin() in bazel/grpc_build_system.bzl has a genrule that uses the same name for both the rule and its output file. This macro gets used in src/compiler/BUILD to define the above plugin targets.
We address this by giving the rule's output file a different name from the rule. This avoids needing to update all the existing references to the plugin rules.
Closes#39060Closes#39165
PiperOrigin-RevId: 766690690
Our test script broke with Bazel 8 because it changed where it puts executables. The Bazel team suggested using `rlocation` to fix this (like b09335b86e). This should fix our C# and Objective-C codegen tests.
Partial commit of #38254Closes#38479
PiperOrigin-RevId: 716341395
Apply Obsolete attribute to deprecated services and methods in C#
generated code
Fix for https://github.com/grpc/grpc/issues/28597
- Deprecated support for enums and enum values is already fixed by
https://github.com/protocolbuffers/protobuf/pull/10520 but this is not
yet released. It is fixed in Protocol Buffers v22.0-rc1 but the gRPC
repo currently has 21.12 as the protocol buffers submodule.
- Deprecated support for messages and fields already exists in the
protocol buffers compiler.
The fix in this PR adds `Obsolete` attribute to classes and methods for
deprecated services and methods within services. e.g.
```
service Greeter {
option deprecated=true; // service level deprecated
// Sends a greeting
rpc SayHello (HelloRequest) returns (HelloReply) {
option deprecated=true; // method level deprecated
}
}
```
I couldn't find any protocol buffers plugin tests to update. Tested
locally.