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.
starting to make `RepeatedField` quack like an array
additional changes:
* make sure gemspec gets all ruby code files
* add homepage in gem spec removes one of the warnings, and the gem spec authors are pushing
everyone to include a homepage in the gem
* remove excess whitespace in test suite to bring formatting inline with the rest of the file
All referring projects are now .NET 4 client rather than .NET 3.5.
This commit also fixes up the ProtoBench app, which I'd neglected in previous commits. (Disentangling the two sets of changes would be time-consuming.)
Move to a single solution file containing all of the C# projects, but no other solution folders - it's easier to edit those files outside VS than keep adding and removing them from the project.
The AddressBook protos have been regenerated (with a change to the example proto which I haven't included in this change - I'll wait for us to decide exactly what we're doing with namespaces before changing protos outside the csharp directory.
Note that now we've got Addressbook.cs which contains AddressBook and Addressbook classes. It's bad enough that we've got a class called AddressBook within a namespace of AddressBook (hard to get away from) but having things vary just by case is nasty.
This is more evidence that an option for renaming the file and descriptor class would be welcome. (A single option can probably handle both.)
This could potentially be added back in later, but its use is limited and it's a pain in terms of support in PCL environments.
One use that has been highlighted is passing objects between AppDomains; we'd recommend passing a byte array explicitly and reparsing on the other side.
1) Project files for different configurations - we're going to look at all this again, ideally to just have a single PCL-compatible build
2) ProtoGen - the C++ generator is now the only one we care about
3) Proto files - these are mostly duplicates (or older versions) of the ones in the common directories
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
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
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
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
