We use a custom allocator for map fields and this allocator must be
passed correctly to hash_map to make sure it's allocated properly
with our custom allocator.
Change-Id: Ie59fa24bf11ff28ffd0fa870e24e456c66b2b9c5
- Style fixups in the code.
- map<> serialization fixes and more tests.
- Autocreation of map<> fields (to match repeated fields).
- @@protoc_insertion_point(global_scope|imports).
- Fixup proto2 syntax extension support.
- Move all startup code to +initialize so it happen on class usage and not app startup.
- Have generated headers use forward declarations and move imports into generated code, reduces what is need at compile time to speed up compiled and avoid pointless rippling of rebuilds.
When compiling a protobuf with gcc 3.3.2 for powerpc, I ran into the
following warning message:
INFO: From Compiling my_proto.pb.cc powerpc-603e-linux-gcc:
bazel-out/local_linux-dbg/genfiles/my_proto.pb.cc: In member
function `virtual void MyProto::Clear()':
bazel-out/local_linux-dbg/genfiles/my_proto.pb.cc:223: warning: this
decimal constant is unsigned only in ISO C90
The line in the proto file that was triggering it was:
if (_has_bits_[24 / 32] & 4278190080) {
ZR_(field1_, field2_);
}
_has_bits_ is a uint32. The constant mask should therefore be
unsigned. This change updates the constant to be generated as
unsigned.
Remove the ClassList support (maybe bring it back in the future).
Trim the includes to hopefully get a working Window build.
Add some more returns after switches for compilers that warn even when all values of the enum are handled.
Use ghtonl instead of htonl.
Change the use of [u]int(8,32)_t within the ObjC generator code to [u]int(8,32) to match the rest of the compiler.
Add objective-c generator files to Visual Studio project.
This is the start of establishing a C# namespace of "Google.ProtocolBuffers.TestProtos.Proto3" for proto3-syntax protos.
We could optionally split the directory structure as well into Proto2 and Proto3 for clarity.
This is a follow up CL for df184fba00
(Id937e25bbb35968ee76c92bd4a8ce6247408c443), which added
#undef GOOGLE_PROTOBUF_MISSING_HASH
where GOOGLE_PROTOBUF_MISSING_HASH macro is never defined.
With this CL, GOOGLE_PROTOBUF_MISSING_HASH macro will be cleaned up
after it is used.
This is less ideal from a dex count perspective because it requires a
new variable for each message, and because most apps have proguard
rules that will ensure that CREATOR classes are retained.
However, it is required to be able to use nano protos inside of AIDL
files, as the autogenerated AIDL code fails to compile otherwise. This
is a substantial benefit as it allows for backwards-compatible
parameters and return types in AIDL methods along the lines of
safeparcel.
Bug: 19084705
Change-Id: I66a2c0424b96cf8ff6b631b186cc4f9407dfc1f4
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
I wasn't able to get the clear() method to inline into the
constructor when optimizations are on in proguard. As a result,
every message has an extra superfluous kept method assuming the
app never uses clear() directly.
There are a couple of instances where setting this option false is
necessary in order to get code dexing successfully without hitting
the method limit, e.g. https://goto.google.com/tltzq
In this example, I tried turning on the method/inlining/unique and
method/inlining/short optimizations before resorting to adding the
generate_clear option, but the method count did not decrease. The
clear() methods were contributing over a thousand extra methods.
Change-Id: If6a9651d6a59cdf70b1040d8248779710ac73105
@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
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
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
Feng Xiao
Jie Luo
unknown
TeBoring
Jorge Canizales
Thomas Van Lenten
Austin Schuh
Jon Skeet
Tamir Duberstein
Yohei Yukawa
Jie Luo
Jeff Davidson
Brian Duff
Ezequiel Lara Gomez
Jan Tattermusch