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
Fix for https://github.com/grpc/grpc/issues/34113 - setting C# option
base_namespace to an empty string results in inconsistent behavior
Allow the `base_namespace` option in the protocol buffers C# gRPC plugin
to be specified with an empty string to make sure the plugin has the
same behaviour as the protocol buffers compiler.
Reverts grpc/grpc#32636
```
src/compiler/csharp_generator_helpers.h:25:7: error: no member named 'compiler' in namespace ...
src/compiler/csharp_generator_helpers.h:25:25: error: no member named 'csharp' in namespace 'compiler' ...
```
Added `base_namespace` experimental option to `grpc_csharp_plugin` as
this has been requested several times by
people not using `Grpc.Tools` to generate their code - see
https://github.com/grpc/grpc/issues/28663
Notes:
- it should not be used with `Grpc.Tools`. That has a different way of
handling duplicate proto file names in different directories. Using this
option will break those builds. It can only be used on the `protoc`
command line.
- it uses common code with the `base_namespace` option for C# in
`protoc`, which unfortunately has a slightly different name mangling
algorithm for converting proto file names to C# camel case names. This
only affects files with punctation or numbers in the name. This should
not matter unless you are expecting specific file names
- See
https://protobuf.dev/reference/csharp/csharp-generated/#compiler_options
for an explanation of this option
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.
Initial bazel tests for C# protoc and grpc_protoc_plugin.
This initial test just generated code from the proto file and compares
the generated code against expected files.
I've put the tests in `test/csharp/codegen` as that is similar to where
the C++ tests are placed, but they could be moved to
`src\csharp` if that is a better place.
Further tests can be added once the initial framework for the tests is
agreed.
