Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CSHARP] Add base_namespace experimental option to C# plugin #32636

Merged
merged 8 commits into from Apr 27, 2023

Conversation

tonydnewell
Copy link
Contributor

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 #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

@tonydnewell
Copy link
Contributor Author

@jtattermusch for review

@jtattermusch jtattermusch added the release notes: yes Indicates if PR needs to be in release notes label Mar 27, 2023
Copy link
Contributor

@jtattermusch jtattermusch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this looks good but opens up some discussion. I'm also wondering whether we should add bazel tests for codegen first, so that we can add this feature in a more controlled way.

// uses common code with protoc. For most file names this will not
// make a difference (only files with punctuation or numbers in the
// name.)
// Otherwise the behavor remains the same as before.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: behavior

if (base_namespace.empty()) {
out_file = grpc_generator::FileNameInUpperCamel(file, false) + file_suffix;
} else {
out_file = GetOutputFile(file, file_suffix, true, base_namespace, error);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// name.)
// Otherwise the behavor remains the same as before.
if (base_namespace.empty()) {
out_file = grpc_generator::FileNameInUpperCamel(file, false) + file_suffix;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wondering why we haven't always been using protobuf's GetOutputFile implementation? It would be good to do a quick check (e.g. take a closer look at history of implementations for grpc and protobuf) to find out the reason just to make sure we didn't forget about anything.

Also, looks like at this point we could probably switch to "GetOutputFile" implementation for the default case as well, after which file names produces by grpc_csharp_plugin and protoc would be 100% consistent in handling corner cases in file naming. But I think to avoid issues with backward compatibility of the Grpc.Tools msbuild stack (which needs to know the file names exactly) we'd rather not do this.
But it's good to know this is an option for future debates.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like GetOutputFile has been exported publicly for 7 years. Not sure why it wasn't used before.

Changing the plugin to always use GetOutputFile could be a potentially breaking change for some users. I wouldn't want to do it yet, but could do in a future release of Grpc.Tools. The change would have to be documented. Also anyone using their own build of the plugin (e.g. on unsupported platforms like Alpine) may break if the Grpc.Tools logic is out of sync with their plugin.

@@ -43,6 +43,8 @@ class CSharpGrpcGenerator : public grpc::protobuf::compiler::CodeGenerator {
bool generate_client = true;
bool generate_server = true;
bool internal_access = false;
std::string base_namespace = "";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we'll probably need to introduce a bazel test for the grpc_csharp_plugin, that does something similar to the C++ golden file test

grpc_sh_test(

at least having a golden file for C# would be a good way of making the diff in the generated code visible in PR reviews. Also, we could have different variants of the test generate code with different options.

--grpc_out=OUT_DIR --grpc_opt=lite_client,no_server \
To use these options with `Grpc.Tools` specify them in the __GrpcOutputOptions__
metadata in the `<Protobuf>` item.
- Note: `file_suffix` and `base_namespace` should not be used with `Grpc.Tools`. Using them will break the build.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add a note that when base_namespace is used, it changes the algorithm for generating file name from the name of the proto file slightly (this might be quite important for users and currently it's only mentioned in a comment in the implementation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: add link to "https://protobuf.dev/reference/csharp/csharp-generated/#compiler_options" in "same as base_namespace for protoc C# options"?

metadata in the `<Protobuf>` item.
- Note: `file_suffix` and `base_namespace` should not be used with `Grpc.Tools`. Using them will break the build.

To use these options on the command line specify them using the `--grpc_opt`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless that's mentioned somewhere, also mention that the "csharp" codegen itself (for protobuf messages), uses --csharp_opt flag.
Also, probably add --csharp_opt to the example, since it's more realistic that actual users will want to set base_namespace for both --grpc_opt and --csharp_opt shall they use the base_namespace option.

Copy link
Contributor

@jtattermusch jtattermusch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this looks good, but I'd prefer to hold until we have the bazel codegen tests in place.

@jtattermusch jtattermusch changed the title Add base_namespace experimental option to C# plugin [csharp] Add base_namespace experimental option to C# plugin Mar 31, 2023
@jtattermusch
Copy link
Contributor

I just merged #32734, so I think you should rebase and provide a codegen test for when the base_namespace option is enabled? (something simple is enough, e.g. run grep to check that the important parts of the generated file contain the expected stuff there when the option is set and aren't there if it's not set)

@tonydnewell
Copy link
Contributor Author

@jtattermusch
Added bazel tests.
This should probably be merged after #32414
Both modify the BUILD bazel file so some merging/editing may need to be done before this can be merged.

@apolcyn apolcyn changed the title [csharp] Add base_namespace experimental option to C# plugin [CSHARP] Add base_namespace experimental option to C# plugin Apr 27, 2023
@apolcyn apolcyn merged commit d534b4a into grpc:master Apr 27, 2023
63 checks passed
drfloob added a commit that referenced this pull request Apr 27, 2023
@@ -22,13 +22,30 @@
#include "src/compiler/config.h"
#include "src/compiler/generator_helpers.h"

using google::protobuf::compiler::csharp::GetOutputFile;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tonydnewell we needed to revert this in #32636 because of some internal build errors, basically the following:

src/compiler/csharp_generator_helpers.h:25] error: no member named 'compiler' in namespace 'google::protobuf'
using google::protobuf::compiler::csharp::GetOutputFile;

I have not gotten too far into the details but I'm wondering if the google::protobuf::compiler::csharp::GetOutputFile is a new API, only in some older versions of protobuf, or something else like that.

veblush pushed a commit that referenced this pull request Apr 27, 2023
…#32957)

Reverts #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' ...
```
@copybara-service copybara-service bot added the imported Specifies if the PR has been imported to the internal repository label Apr 28, 2023
XuanWang-Amos pushed a commit to XuanWang-Amos/grpc that referenced this pull request May 1, 2023
)

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
grpc#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
XuanWang-Amos pushed a commit to XuanWang-Amos/grpc that referenced this pull request May 1, 2023
…grpc#32957)

Reverts 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' ...
```
paulosjca pushed a commit to paulosjca/grpc that referenced this pull request May 4, 2023
)

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
grpc#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
paulosjca pushed a commit to paulosjca/grpc that referenced this pull request May 4, 2023
…grpc#32957)

Reverts 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' ...
```
wanlin31 pushed a commit that referenced this pull request May 18, 2023
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
#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
wanlin31 pushed a commit that referenced this pull request May 18, 2023
…#32957)

Reverts #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' ...
```
jtattermusch added a commit that referenced this pull request Jun 26, 2023
… patch) (#33535)

Reintroduces patched version of #32636
(which was reverted in #32957).

Together with cl/542843305, the internal build should work fine.

Supersedes #33310 (since a patch is
also needed).

---------

Co-authored-by: tony <tony.newell@pobox.com>
mario-vimal pushed a commit to mario-vimal/grpc that referenced this pull request Jul 13, 2023
… patch) (grpc#33535)

Reintroduces patched version of grpc#32636
(which was reverted in grpc#32957).

Together with cl/542843305, the internal build should work fine.

Supersedes grpc#33310 (since a patch is
also needed).

---------

Co-authored-by: tony <tony.newell@pobox.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bloat/none imported Specifies if the PR has been imported to the internal repository lang/C# per-call-memory/neutral per-channel-memory/neutral release notes: yes Indicates if PR needs to be in release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants