grpc-gateway
grpc-gateway copied to clipboard
openapiv2.proto NULL conflict with c++ keyword
https://github.com/grpc-ecosystem/grpc-gateway/blob/3ad0fb96ecfdf73fa2eddb3de116ae98360dbb35/protoc-gen-swagger/options/openapiv2.proto#L218
compiled openapiv2.proto cpp file contains NULL, conflict with c++ keyword. Any suggestion on how to solve this?
Not sure if we can rename this without causing trouble. @ivucica what do you think?
I've tried blindly invoking --cpp_out=.......
on a project where I'm already using --go_out=.....
and I took a peek at the generated code. I don't see the code contains NULL
.
I've then realized I also need to --cpp_out=.....
the protoc-gen-swagger/options/{annotations,openapiv2}.proto
as the generated code depends on this being generated, so I did that too.
In my case, the generated code is:
enum JSONSchema_JSONSchemaSimpleTypes {
JSONSchema_JSONSchemaSimpleTypes_UNKNOWN = 0,
JSONSchema_JSONSchemaSimpleTypes_ARRAY = 1,
JSONSchema_JSONSchemaSimpleTypes_BOOLEAN = 2,
JSONSchema_JSONSchemaSimpleTypes_INTEGER = 3,
JSONSchema_JSONSchemaSimpleTypes_NULL = 4,
JSONSchema_JSONSchemaSimpleTypes_NUMBER = 5,
JSONSchema_JSONSchemaSimpleTypes_OBJECT = 6,
JSONSchema_JSONSchemaSimpleTypes_STRING = 7,
JSONSchema_JSONSchemaSimpleTypes_JSONSchema_JSONSchemaSimpleTypes_INT_MIN_SENTINEL_DO_NOT_USE_ = ::google::protobuf::kint32min,
JSONSchema_JSONSchemaSimpleTypes_JSONSchema_JSONSchemaSimpleTypes_INT_MAX_SENTINEL_DO_NOT_USE_ = ::google::protobuf::kint32max
};
As you can tell, the symbol is not NULL
, it is JSONSchema_JSONSchemaSimpleTypes_NULL
. Unless an alternative generator is being used, this is not a problem. Looking for one of the other entries in that enum
such as NUMBER
doesn't reveal troubling use in the generated code either.
Perhaps the implementation code (.pb.cc
) is the problem? It has this:
#if !defined(_MSC_VER) || _MSC_VER >= 1900
const JSONSchema_JSONSchemaSimpleTypes JSONSchema::UNKNOWN;
const JSONSchema_JSONSchemaSimpleTypes JSONSchema::ARRAY;
const JSONSchema_JSONSchemaSimpleTypes JSONSchema::BOOLEAN;
const JSONSchema_JSONSchemaSimpleTypes JSONSchema::INTEGER;
const JSONSchema_JSONSchemaSimpleTypes JSONSchema::NULL;
const JSONSchema_JSONSchemaSimpleTypes JSONSchema::NUMBER;
const JSONSchema_JSONSchemaSimpleTypes JSONSchema::OBJECT;
const JSONSchema_JSONSchemaSimpleTypes JSONSchema::STRING;
const JSONSchema_JSONSchemaSimpleTypes JSONSchema::JSONSchemaSimpleTypes_MIN;
const JSONSchema_JSONSchemaSimpleTypes JSONSchema::JSONSchemaSimpleTypes_MAX;
const int JSONSchema::JSONSchemaSimpleTypes_ARRAYSIZE;
#endif // !defined(_MSC_VER) || _MSC_VER >= 1900
But that is namespaced.
Trying to compile this:
$ g++ -I ../../../ ../../../protoc-gen-swagger/options/openapiv2.pb.cc -C -o tmp.o
In file included from /usr/include/x86_64-linux-gnu/bits/types/stack_t.h:23:0,
from /usr/include/signal.h:303,
from /usr/include/x86_64-linux-gnu/sys/param.h:28,
from /usr/include/google/protobuf/stubs/port.h:64,
from /usr/include/google/protobuf/stubs/common.h:46,
from ../../../protoc-gen-swagger/options/openapiv2.pb.h:9,
from ../../../protoc-gen-swagger/options/openapiv2.pb.cc:4:
../../../protoc-gen-swagger/options/openapiv2.pb.h:1845:38: error: expected unqualified-id before ‘__null’
static const JSONSchemaSimpleTypes NULL =
^
../../../protoc-gen-swagger/options/openapiv2.pb.cc:927:52: error: expected unqualified-id before ‘__null’
const JSONSchema_JSONSchemaSimpleTypes JSONSchema::NULL;
So now we've gotten somewhere.
The issue is that NULL is #define
d to __null
, breaking namespacing, and separately that in at least one place it's declared (statically) without namespacing.
Thinking a bit about this, we could hack this and comment out NULL
. But, I don't believe the right place to tackle this is grpc-gateway
. The right places are either the protoc
compiler's cpp
generator, or standard headers.
The hack we could put in place is rename the field, then special-case the value when outputting this field into .json
. This hack would make me unhappy as it doesn't solve the underlying issue of protoc
spitting out bad C++ even when supplied with valid .proto
schema. But, if done well and covered with a good test, I would (reluctantly) LGTM it. We are likely to break some .proto
schemas that may be using this enum value, but if there's no activity on https://github.com/protocolbuffers/protobuf/issues/6609, I'd accept a patch.
I do recommend the patch to be sent to https://github.com/protocolbuffers/protobuf/issues/6609 instead, if possible.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
We should leave it open