NOTE: This is a binary breaking change as structure sizes have changed size
and/or order.
- Drop capturing field options, no other options were captured and other mobile
targeted languages don't try to capture this sort information (saved 8
bytes for every field defined (in static data and again in field descriptor
instance size data).
- No longer generate/compile in the messages/enums in descriptor.proto. If
developers need it, they should generate it and compile it in. Reduced the
overhead of the core library.
- Compute the number of has_bits actually needs to avoid over reserving.
- Let the boolean single fields store via a has_bit to avoid storage, makes
the common cases of the instance size smaller.
- Reorder some flags and down size the enums to contain the bits needed.
- Reorder the items in the structures to manually ensure they are are packed
better (especially when generating 64bit code - 8 bytes for every field,
16 bytes for every extension, instance sizes 8 bytes also).
- Split off the structure initialization so when the default is zero, the
generated static storage doesn't need to reserve the space. This is batched
at the message level, so all the fields for the message have to have zero
defaults to get the saves. By definition all proto3 syntax files fall into
this case but it also saves space for the proto2 that use the standard
defaults. (saves 8 bytes of static data for every field that had a zero
default)
- Don't track the enums defined by a message. Nothing in the runtime needs it
and it was just generation and runtime overhead. (saves 8 bytes per enum)
- Ensure EnumDescriptors are started up threadsafe in all cases.
- Split some of the Descriptor initialization into multiple methods so the
generated code isn't padded with lots of zero/nil args.
- Change how oneof info is feed to the runtime enabling us to generate less
static data (8 bytes saved per oneof for 64bit).
- Change how enum value informat is capture to pack the data and only decode
it if it ends up being needed. Avoids padding issues causing bloat of 64bit,
and removes the needs for extra pointers in addition to the data (just the
data and one pointer now).
- Convert most of the core library headers over to HeaderDoc format.
- Switch the generated comments over to HeaderDoc.
- Create GPBCodedOutputStream_PackagePrivate and move some things into there
that should be more internal.
- Extend GPB*ObjectDictionary to support generic syntax.
- Update the generator to output generics so the enclosed type is exposed for compiler checks.
- Use generics in a the public interfaces.
- Update the generated sources that are checked in.
Recently, descriptor.proto gained a GeneratedCodeInfo message, which means the generated code conflicts with our type.
Unfortunately this affects codegen as well, although this is a part of the public API which is very unlikely to affect hand-written code.
Generated code changes in next commit.
Move the original README.md to src since it's talking about C++
exclusively and add a more general README.md to document how
to install protoc for all languages.
Fixesgoogle/protobuf#693
msan flags this as being undefined behavior. I think it's triggering
because the compiler has to insert a branch to avoid changing the
pointer's value if it starts out NULL. I can't figure out if this is
actually undefined behavior or not, but it definitely seems to be a gray
area of the standard which is best avoided.
Defer calls to mutable_unknown_fields() until it is actually required to
save memory for C++ lite runtime.
Change-Id: Ica9c1fd276cdb164942d1e7b6e098c83ee3ffdc5
This addresses issue #1008, by creating a JsonFormatter which is private and only different
to JsonFormatter.Default in terms of reference equality.
Other plausible designs:
- The same, but expose the diagnostic-only formatter
- Add something to settings to say "I don't have a type registry at all"
- Change the behaviour of JsonFormatter.Default (bad idea IMO, as we really *don't* want the result of this used as regular JSON to be parsed)
Note that just trying to find a separate fix to issue #933 and using that to override Any.ToString() differently wouldn't work for messages that *contain* an Any.
Generated code changes follow in the next commit.
When building for 64-bit big endian MIPS I was getting undefined
references to the following four functions during linking.
NoBarrier_AtomicIncrement
NoBarrier_Store
NoBarrier_AtomicExchange
NoBarrier_Load
Adding 64-bit versions of them to atomicops_internals_generic_gcc.h
fixed the compilation issues.
This is adapted from the branch of @xfxyjwf at:
494716a682
and should solve the protobuf compilation problem against nvcc.
Tested against nvcc 6.5 and 7.0.
Jisi Liu
topillar
Thomas Van Lenten
Ben Vanik
Antal Tátrai
Josh Haberman
Sergio Campama
murgatroid99
Gregor Jasny
Clement Courbet
Joshua Humphries
Jon Skeet
Dongjoon Hyun
Swen Kooij
kkm
Feng Xiao
Brian Silverman
John Burke
Kenichiro IDA
Mark Whiting
Yangqing Jia
Kal Conley
Bo Yang