| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
We no longer supports nano and recommend protobuf lite over nano for
Android users.
|
|
|
|
| |
The first is the newer name, which is also more telling.
|
|
|
|
|
| |
The "New BSD License" is the "3-Clause BSD License", but the links were
pointing to the "2-Clause BSD License".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Down-integrate internal changes to github.
* Update conformance test failure list.
* Explicitly import used class in nano test to avoid random test fail.
* Update _GNUC_VER to use the correct implementation of atomic operation
on Mac.
* maps_test.js: check whether Symbol is defined before using it (#2524)
Symbol is not yet available on older versions of Node.js and so this
test fails with them. This change just directly checks whether Symbol is
available before we try to use it.
* Added well_known_types_embed.cc to CLEANFILES so that it gets cleaned up
* Updated Makefile.am to fix out-of-tree builds
* Added Bazel genrule for generating well_known_types_embed.cc
In pull request #2517 I made this change for the CMake and autotools
builds but forgot to do it for the Bazel build.
* Update _GNUC_VER to use the correct implementation of atomic operation on Mac.
* Add new js file in extra dist.
* Bump version number to 3.2.0
* Fixed issue with autoloading - Invalid paths (#2538)
* PHP fix int64 decoding (#2516)
* fix int64 decoding
* fix int64 decoding + tests
* Fix int64 decoding on 32-bit machines.
* Fix warning in compiler/js/embed.cc
embed.cc: In function ‘std::string CEscape(const string&)’:
embed.cc:51:32: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (int i = 0; i < str.size(); ++i) {
^
* Fix include in auto-generated well_known_types_embed.cc
Restore include style fix (e3da722) that has been trampled by
auto-generation of well_known_types_embed.cc
* Fixed cross compilations with the Autotools build
Pull request #2517 caused cross compilations to start failing, because
the js_embed binary was being built to run on the target platform
instead of on the build machine. This change updates the Autotools build
to use the AX_PROG_CXX_FOR_BUILD macro to find a suitable compiler for
the build machine and always use that when building js_embed.
* Minor fix for autocreated object repeated fields and maps.
- If setting/clearing a repeated field/map that was objects, check the class
before checking the autocreator.
- Just to be paranoid, don’t mutate within copy/mutableCopy for the autocreated
classes to ensure there is less chance of issues if someone does something
really crazy threading wise.
- Some more tests for the internal AutocreatedArray/AutocreatedDictionary
classes to ensure things are working as expected.
- Add Xcode 8.2 to the full_mac_build.sh supported list.
* Fix generation of extending nested messages in JavaScript (#2439)
* Fix generation of extending nested messages in JavaScript
* Added missing test8.proto to build
* Fix generated code when there is no namespace but there is enum definition.
* Decoding unknown field should succeed.
* Add embed.cc in src/Makefile.am to fix dist check.
* Fixed "make distcheck" for the Autotools build
To make the test pass I needed to fix out-of-tree builds and update
EXTRA_DIST and CLEANFILES.
* Remove redundent embed.cc from src/Makefile.am
* Update version number to 3.2.0-rc.1 (#2578)
* Change protoc-artifacts version to 3.2.0-rc.1
* Update version number to 3.2.0rc2
* Update change logs for 3.2.0 release.
* Update php README
* Update upb, fixes some bugs (including a hash table problem). (#2611)
* Update upb, fixes some bugs (including a hash table problem).
* Ruby: added a test for the previous hash table corruption.
Verified that this triggers the bug in the currently released
version.
* Ruby: bugfix for SEGV.
* Ruby: removed old code for dup'ing defs.
* Reverting deployment target to 7.0 (#2618)
The Protobuf library doesn’t require the 7.1 deployment target so
reverting it back to 7.0
* Fix typo that breaks builds on big-endian (#2632)
* Bump version number to 3.2.0
|
|
|
| |
This class is declared to be final, but declares fields to be protected. Since the class is final, it can not be derived from, and the use of protected is confusing.
|
| |
|
|
|
|
|
|
| |
[skip ci]
Change-Id: I1ba6f6372a08b5796570851336e1a548602f60da
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Protoc, C++ runtime and Java runtime are updated to v3.0.0-beta-1, other
languages are updated to v3.0.0-alpha-4.
|
|\ |
|
|/
|
|
| |
Also introducing an option javanano_use_deprecated_package to allow users to disable the suffix
|
|\
| |
| | |
Speed up little endian int/long writes.
|
| |
| |
| |
| |
| | |
default configuration. In default configuration, maven needs webdav for
deployment, which cannot be found in central repository.
|
| | |
|
| | |
|
|/
|
|
|
| |
Bug: 20636336
Change-Id: I303d712967f9885f7c3082d00f961f8ab93a6aed
|
|
|
|
| |
Change-Id: I845ee1ab1005d25c8d77a8c2ed801c0f7b7c847b
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a MessageNano containing a String is serialized into a buffer that
is too small to contain it, and the buffer's boundary happens to be
where the string field's length delimiting varint is serialized,
and the string's length and 3*length have the same length when
encoded as a varint, an IllegalArgumentException is thrown rather than
an OutOfSpaceException.
Github issue: https://github.com/google/protobuf/issues/292
Change-Id: If478d68cf15bfd0662252d008e42b2bf1ff1c75e
|
|
|
|
|
|
|
|
|
|
| |
It turns out dex (apparently) was inlining these protected final
methods from ExtendableMessageNano into every message class. Removing
these methods from the base class and inlining their code reduces
the method count by 2 methods / message when the store_unknown_fields
option is on.
Change-Id: I0aa09f2016d39939c4c8b8219601793b8fab301f
|
|
|
|
|
|
|
|
|
|
| |
@IntDef is a support library annotation which allows build tools to
determine the valid set of values for a given integer field when that
field is intended to be restricted like an enum. This avoids the
overhead of enums while still allowing for compile-time type checking
in most circumstances.
Change-Id: Iee02e0b49a8e069f6456572f538e0a0d301fdfd5
|
|
|
|
| |
Change-Id: Ie2a9e36276ac35e10b3f8d379b5742d50a0374e9
|
|
|
|
|
|
|
|
|
|
|
| |
When building, some instances expect createMessageTyped to have the signature
(int, Class, long), while others expect (int, Class, int). Simply having
the former signature meant that builds expecting the latter would fail.
This is a cherrypick of change b2a9d4321578139677c146ce37eba5e27e8f5c79
from master.
Change-Id: Ib02dbf66173510f4edea32c7b43e82c1a7a38aa2
|
|
|
|
| |
Change-Id: I85563b74237d38c1e447b7286f5f6e62d57e3d63
|
|
|
|
|
|
| |
Upstreamed from Another Place (cr/57247854).
Change-Id: I2aaf59544c0f5ae21a51891d8a5eeda1dc722c90
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://android-review.googlesource.com/#/c/67890/ removed field
initialization from the ctor, making it just call clear() instead.
When I added the generate_clear option back (as part of the reftypes
compat mode) in https://android-review.googlesource.com/#/c/109530/,
I forgot to ensure that what clear() used to do was inlined in the
constructor.
This change fixes NPEs that are happening for users of
reftypes_compat_mode who rely on unset repeated fields being empty
arrays rather than null.
Change-Id: Idb58746c60f4a4054b7ebb5c3b0e76b16ff88184
|
|
|
|
|
|
| |
Forgot to update these in https://android-review.googlesource.com/#/c/109809/
Change-Id: I53f838e2f134f53964161d9620d5ead00c4a3939
|
|
|
|
|
|
|
| |
Measuring the serialized size of nano protos is now a zero-alloc operation, and serializing a proto now allocates no memory (other than the output buffer) instead of O(total length of strings).
Change-Id: Id5e2ac3bdc4ac56c0bf13d725472da3a00c9baec
Signed-off-by: Charles Munger <clm@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, extensions with field numbers greater than 268435455 would
result in a compile time error in generated code that looks something
like this:
Foo.java:3178: error: integer number too large: 3346754610
3346754610);
This is because we were trying to represent the tag number (an
unsigned int) using a java int constant, but java int constants are
signed, and can't exceed Integer.MAX_VALUE.
Fixed by declaring it as a long instead, and casting it down to an
int in the implementation. This is safe, because the tag value always
fits in 32 bis.
Change-Id: If2017bacb4e20af667eaeaf9b65ddc2c30a7709f
|
| |
|
| |
|
| |
|
|\
| |
| | |
Add maven release profile for JavaNano.
|
| |
| |
| |
| | |
Change-Id: I885b561c85325db05595f0d86338dcd7c06cf058
|
|/
|
|
| |
Change-Id: I33479e529b060e4fed532a827a386d3baecc835e
|
|
|
|
| |
Change-Id: Icecb25db34ae5e6d5142a2d75ca7216ba018abb2
|
|
|
|
| |
Change-Id: I4cbb3374e351c31611de472c7d5d78e4ce2b0f3b
|
|
|
|
| |
Change-Id: I6a51a35c69ac24a60dd96ef69d556b1e68bc37d6
|
|
|
|
| |
Change-Id: Iafd4a3aa9d55e31478bf070311eeadfe95ece4d7
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
field oneof support.
|
| |
|
| |
|