Open patrickdepinguin opened 1 week ago
Thanks for reaching out Patrick. This is definitely unintended on our part.
We recently added the compiler tag [[ deprecated ]]
to enums -- prior to this marking enum fields as [deprecated = true]
was a no-op.
I agree that generating warnings in code that user has no control over is a regression.
The best way to fix this would probably be to use the PROTOBUF_IGNORE_DEPRECATION_START
and PROTOBUF_IGNORE_DEPRECATION_STOP
macros to wrap the generated code. The macros are defined here:
https://github.com/protocolbuffers/protobuf/blob/main/src/google/protobuf/port_def.inc#L258-L273
If you feel comfortable modifying the protoc source code, please feel free to send us a PR for this.
Thanks for your guidance. I have a solution locally, will create a PR soon.
What version of protobuf and what language are you using? Version: 3.21.12, but same occurs on latest 28.0 Language: C++
What operating system (Linux, Windows, ...) and version? Linux (e.g. Debian 12 bookworm)
What runtime / compiler are you using (e.g., python version or gcc version) gcc version 12.2.0 (Debian 12.2.0-14)
What did you do? Using following foobar.proto file:
Generate C++ files with:
protoc --cpp_out . foobar.proto
Compile generated source file:g++ -c foobar.pb.cc
What did you expect to see
Compilation without any warnings.
What did you see instead?
In the generated foobar.pb.h header, the declaration of the enum is fine: (PROTOBUF_DEPRECATED_ENUM becomes 'attribute((deprecated))', and in latest 28.0 the code just generates
[[deprecated]]
)However, later in the file, the deprecated 'OK' field is used, which causes the compiler warning:
This is a problem when compiling the code with -Werror, because every warning is then treated as an error (intentionally).
Even when the user is not using the deprecated type in their own code, the generated code still uses it, outside of the user's control. The intention of deprecating a field is to highlight any real uses, not the internal use in code generated by protoc itself.