Shadowed variables can cause readability issues. Ensure a shadowed
variable isn't used in header files which may be used in a dependent
project that explicitly disables them.
Chrome is running into two issues with the use of this macro
in open-source protobuf (https://crbug.com/809157):
1. GOOGLE_FALLTHROUGH_INTENDED is defined to nothing on __APPLE__
platforms, which blocks us from enabling -Wimplicit-fallthrough
on Mac and iOS. (We use a hermetic self-built modern clang,
so whatever Xcode bug that exclusion might be for doesn't apply
to us.)
2. It's in a public header file, and it's included in a public header file.
When clang suggests adding [[clang::fallthrough]], it checks if it knows of
a macro expanding to that and if so, suggests inserting that. Since lots of
chrome code includes protobuf headers, it often suggests inserting
GOOGLE_FALLTHROUGH_INTENDED (from protobuf) instead of the correct
FALLTHROUGH (from chrome's base).
Since the fallthrough doens't do anyting useful, just remove it.
Long ago, this might have had perf impact, but d64a2d9941 added a
parsing fast path that calls this switch as slow fallback, so it should
be off the hot path nowadays.
No intended behavior change.
This is the public version of internal change 184824132.
Fixes: #4256.
Bazel@HEAD supports Java 9.
The current code has one single issue with Java 9 compliance: the usage
of sun.misc package. We add jdk.unsupported module with --add-modules
compiler option for now. Long term, the usage of non public API should
be avoided.
To build with Java 9, build custom bazel version and issue:
$ bazel --host_javabase=/usr/lib64/jvm/java-9-openjdk build \
--javacopt='--release 9' \
--java_toolchain=@bazel_tools//tools/jdk:toolchain_jdk9 \
:protobuf_java
Haven't been able to make a repo case, but this should "fix" the problem
by avoid it completely.
- Move readOnlySemaphore_ into the .m file so it isn't exposed in any
header.
- Move GPBGetObjectIvarWithField() also to go with the new limited
visibility on the readOnlySemaphore_.
The Undefined Behavior sanitizer flags one part of the unittests for this.
For default values for `bytes` we write a length on the front of a c-string
in the static data, apparently the compiler/linker doesn't always make this
4 byte aligned, so it get flagged for undefined/degraded performance. Avoid
this by using memcpy instead.
Fixes issue #1154 by noting that `vcpkg` contains protobuf. Potential improvements: also remark how to use `vcpkg` to get dependencies when building from source via CMake.
These statements pulled a bunch of symbols from the std namespace into
the global namespace. This commit removes all of them except for
std::string, which is a bit trickier to remove.
Remove broken link to RPC implementation https://code.google.com/p/protorpc/. Going to this URL displays a 404 error message, with no indication that the project has a new location or still exists.
This will allow SourceLink as per #4179, and mean that we can use C#
7.0 language features in the library (but not in generated code).
This does not affect which platforms we're *targeting*, so end users
won't see any difference.
It would be nice to update to 2.1.4, but AppVeyor's "Visual Studio
2017" environment is only 2.0.3.
The generated code for enums needs atomics support, so generate the
import instead of relying on it via transitive imports. This will
make future changes to this likely likely to break generated code
and runtime support are mixed.
Followup to https://github.com/google/protobuf/pull/4184.
Followup to https://github.com/google/protobuf/pull/4184, keep the
import to not break any existing generated code that isn't regenerated
when they update to the newer protobuf code.
John Millikin
Feng Xiao
Abdul Sami
Dave Tapuska
Jie Luo
Yilun Chong
Yilun Chong
Thomas Van Lenten
Nico Weber
Corentin Le Molgat
Jisi Liu
Bruno Kim Medeiros Cesar
Adam Cozzette
David Ostrovsky
Ludger Sprenker
Niklas Lochschmidt
Robert Schumacher
Adam Cozzette
Leigh McCulloch
Jon Skeet
Matt Chan