Updating to the current protobuf version caused the following build errors in
Chromium when using Clang on Windows:
..\..\third_party\protobuf\src\google/protobuf/stubs/fastmem.h(67,43) : error: equality comparison with extraneous parentheses [-Werror,-Wparentheses-equality]
if (GOOGLE_PREDICT_FALSE(n_rounded_down == 0)) { // n <= 7
~~~~~~~~~~~~~~~^~~~
The problem is that on Windows, GOOGLE_PREDICT_FALSE is #defined to nothing, so
the code expands to 'if ((n_rounded_down == 0))', which Clang warns about.
Clang would not have warned if the extra parentheses came from the macro,
but in this case they don't because the macro is just dropped.
Fix this by making the macros behave as an identity function instead of just
getting dropped.
This is closer to what these macros look like in stubs/port.h internally.
This compiles with -std=c++11:
message Foo {
map<string, Foo> value = 1;
}
This does not compile:
message Foo {
map<int32, Foo> value = 1;
}
Needs to dig more into the underlying issue.
The internal down-integrate script probably does not handle the
top level macros well. Moved the macro inside of the namespace
declrations to avoid down-integrate errors in the future.
Change-Id: I3790357f36b0204a2a26577805192a3a1e989df8
We now do this in protoc instead of the generation simpler.
Benefits:
- Generation script is simpler
- Detection is simpler as we now only need to care about one filename
- The embedded descriptor knows itself as "google/protobuf/descriptor.proto" avoiding dependency issues
This PR also makes the "invalid dependency" exception clearer in terms of expected and actual dependencies.
We now do this in protoc instead of the generation simpler.
Benefits:
- Generation script is simpler
- Detection is simpler as we now only need to care about one filename
- The embedded descriptor knows itself as "google/protobuf/descriptor.proto" avoiding dependency issues
This PR also makes the "invalid dependency" exception clearer in terms of expected and actual dependencies.
See issue #240 - MSVC in VS2015 seems to inline a function it shouldn't. My original workaround was to disable inlining for the whole file, but I found a way to do it on just this specific function using __declspec(noinline).
Unfortunately __declspec has to go at the start of the function declaration, while __attribute in GCC can go either before or after. I had to move lots of GOOGLE_ATTRIBUTE_NOLINE to make it compile. I have not yet tested this change with GCC.
Will there be other side effects of defining this, given it wasn't previously?
I also noticed a few functions marked with both the 'inline' keyword, and GOOGLE_ATTRIBUTE_NOINLINE - huh? Is there an explanation for this, or is it an oversight?
