Also pre-inlines set() and has() in serialization code. This could
theoretically help ProGuard: the message class size is usually large,
and because of this only, it may refuse to inline an accessor into
the serialization code, and as a result keeps the accessor intact.
Chances are, after pre-inlining all accessor calls within the message
class, those accessors become unused or single-use, so there are more
reasons for ProGuard to inline and then remove them.
Change-Id: I57decbe0b2533c1be21439de0aad15f49c7024dd
- Blank line after opening a message class (but not an enum interface).
- Let all code blocks insert blank lines before themselves. This applies to
'package' statement, all message classes, enum classes or constant groups,
extensions, bitfields, proto fields (one block per field; i.e. accessors
don't have blank lines among them), and basic MessageNano methods. In this
case we don't need to guess what the next block is and create blank lines
for it.
- Fixed some newline/indent errors.
- Only one SuppressWarnings("hiding") per file.
Change-Id: I865f52ad4fb6ea3b3a98b97ac9d78d19fc46c858
The public doc states that repeated fields are simply concatenated
and doesn't impose a different semantics for packed fields. This
CL fixes this for packed fields and adds tests covering all cases.
Also fixed a bit of missed null-repeated-field treatments.
Change-Id: Ie35277bb1a9f0b8171dc9d07b6adf9b9d3308de2
There's no distinction between a repeated field being null and being
empty. In both cases, nothing is sent on the wire. Clients might for
whatever reason inadvertently set a repeated field to null, so
protect against that and treat it just as if the field was empty.
Change-Id: Ic3846f7f2189d6cfff6f8ef3ca217daecc3c8be7
The field initializers have basically caused the compiled <init> method
to inline the whole clear() method, which means if ProGuard is not used
or failed to inline or remove clear(), there are two big chunks of code
that do the same thing. So why not just call clear() from the ctor.
Change-Id: Ief71e2b03db2e059b3bfa98309649368089ffab0
Previously it looked like this:
public final class OuterClass {
[...]
public static final class InnerClass extends
com.google.protobuf.nano.MessageNano {
[...]
public void setId(java.lang.String value) {
if (value == null) {
throw new java.lang.NullPointerException();
}
id_ = value;
bitfield0_ |= 0x00000001;
[...]
}
[...]
}
Now it looks like this:
public final class OuterClass {
[...]
public static final class InnerClass extends
com.google.protobuf.nano.MessageNano {
[...]
public void setId(java.lang.String value) {
if (value == null) throw new java.lang.NullPointerException();
id_ = value;
bitfield0_ |= 0x00000001;
[...]
}
[...]
}
Change-Id: I2a9289b528f785c846210d558206d677aa13e9be
This option generates fields as reference types, and serializes
based on nullness.
Change-Id: Ic32e0eebff59d14016cc9a19e15a9bb08ae0bba5
Signed-off-by: Brian Duff <bduff@google.com>
When parsing a group, the group's end tag should not be stored within the
message's unknownFieldData. Not only does this waste space, it is also output
the next time the group is serialized, resulting in two end tags for that group.
The resulting bytes are not always a valid protocol buffer and may fail to
parse.
This change ensures that group end tags do not result in an unknownFieldData
entry, and that messages with groups can be roundtripped without corruption.
Change-Id: I240f858a7217a7652b756598c34aacad5dcc3363
Conflicts:
java/src/test/java/com/google/protobuf/NanoTest.java
This javanano_out command line option creates a container interface
at the normal place where the enum constants would reside, per enum
definition. The java_multiple_files flag would now affect the file-
scope enums with the shells. If the flag is true then file-scope
container interfaces are created in their own files.
Change-Id: Id52258fcff8d3dee9db8f3d8022147a811bf3565
Max Cai
Brian Duff
Ulas Kirazci
Wink Saville
Andrew Flynn
Nicholas Seckar