Until now this file was just checked into the repo, but actually it
should be generated from any.js, struct.js, and timestamp.js. This
change updates the build system to make this happen. To make it work I
also had to remove some C++11 features from embed.cc.
This #ifdef in hash.h causes us to give up on finding a hash function on
Android, when there do seem to be hash functions available in practice.
I also had to tweak a macro in map.h that was disabling on Android an
allocator construct() method that we need.
There have been some reports that this necessary to prevent build
failures in some environments. It makes sense to do this anyway since
the result of this macro is ultimately assigned to uint32 in the
generated code.
- Check the parent file options for deprecation when deciding to tag Messages
and Enums as deprecated.
- Within the generated source push/pop the warning for implementing deprecated
things around a deprecated class implementation.
- Annotate the methods generated for extension fields as deprecated.
- Add a testing .proto file that covers deprecated fields, messages, enums,
enum values and compile it into the unittests to confirm things compile
cleanly.
- Add a testing .proto file that uses the file level option to make everything
deprecated and compile it into the unittests to confirm things compile
cleanly.
Currently the default for protobuf on Android is to silently drop all log
messages. This makes debugging difficult because things like GOOGLE_LOG(FATAL)
will crash the process without actually logging a useful error.
This CL changes the logging so that by default we send messages for all log
levels to logcat (and stderr). Users can override this by setting
GOOGLE_PROTOBUF_MIN_LOG_LEVEL. Also, that option was not being respected for
non-Android platforms so I went ahead and fixed that to make things consistent.
* Factored Conformance test messages into shared test schema.
* Updated benchmarks to use new proto3 message locations.
* Fixed include path.
* Conformance: fixed include of Python test messages.
* Make maven in Rakefile use --batch-mode.
* Revert changes to benchmarks.
On second thought I think a separate schema for
CPU benchmarking makes sense.
* Try regenerating C# protos for new test protos.
* Removed benchmark messages from test proto.
* Added Jon Skeet's fixes for C#.
* Removed duplicate/old test messages C# file.
* C# fixes for test schema move.
* Fixed C# to use the correct TestAllTypes message.
* Fixes for Objective C test schema move.
* Added missing EXTRA_DIST file.
Swift generators should default to CamelCasing the proto package and prefixing
symbols with that, but this option allows developers to override that behavior
with something custom if they desire.
Fixes https://github.com/google/protobuf/issues/1833
This seems to be necessary to prevent warnings in some compiler
configurations, particularly for tag numbers that are too large to fit
in a signed 32-bit int.
Behavior of define GOOGLE_PROTOBUF_NO_STATIC_INITIALIZER has been
altered between 337a028 and cc8ca5b for C++.
See github issue #2385 for further details.
In php, class name cannot be "Empty". Modified code generator to (#2375) generate GPBEmpty instead (for google.protobuf.Empty only). Also change
runtime code to work with the new generated code accordingly.
It turns out calling StringOutputStream::Next()/BackUp() repeatedly is
very costly in opensource protobuf because it keeps resize() the string
back and forth. The current JSON conversion API suffers this problem and
leads to ridiculously long parsing time:
https://github.com/google/protobuf/issues/2305#issuecomment-257785492
This change fixes the problem but caching the buffer of Next() and avoid
calling BackUp() as much as possible.
The size parameter is only used in cases where the compiler supports
sized delete, so when that's not available we need to specifically cast
it to void to prevent a warning.
When running >bazel test :protobuf_test a few compiler warnings came up. They were centered around the usage of "int" as the loop counter where the value should have been a size_t.
ARM specific CONFIG_KUSER_HELPERS feature can be disabled in Linux kernel,
and in this case, we shouldn't crash. Use gcc built-in functions instead
of arm specific code if they are available.