aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/google/protobuf/compiler/javanano/javanano_extension.cc
Commit message (Collapse)AuthorAge
* Remove javanano.Gravatar Feng Xiao2018-03-26
|
* Add std:: namespace prefix to set and map (#3332)Gravatar tanderson-google2017-07-09
| | | * Remove using std::{set,map}
* Fix bug with large extension field numbers.Gravatar Brian Duff2015-04-28
| | | | | | | | | | | | | | | | | | | 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
* Extension overhaul.Gravatar Max Cai2014-01-10
| | | | | | | | | | | | | | | | | | | | | | - Get rid of TypeLiteral<T>. It was introduced to read the component type of a List<T> at runtime. But we use arrays everywhere else, and we can always read the component type of an array type at runtime. - Properly read/write "minor" types (e.g. sint32, sfixed32). The old implementation could only read/write data as the "typical" types (one per Java type), e.g. java.lang.Integer -> int32, java.lang.Long -> int64. So if e.g. an extension specifies sfixed32 as the type, it would be read/written in the totally incompatible int32 format. - Properly serialize repeated packed fields. The old implementation doesn't do packed serialization. As an added bonus, and to be more aligned with the rest of protobuf nano / main, repeated packable extensions can deserialize both packed and non-packed data. - Split Extension class into a hierarchy so under typical usage a large chunk of code dealing with primitive type extensions can be removed by ProGuard. Bug: https://code.google.com/p/android/issues/detail?id=62586 Change-Id: I0d692f35cc2a8ad3a5a1cb3ce001282b2356b041
* Make generated code more aligned with Google Java style.Gravatar Max Cai2013-10-16
| | | | | | | | | | | | | | - 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
* Update nano to serialize java keywords properly.Gravatar Tom Chao2013-07-19
| | | | Change-Id: I7407d0fab609c336ecd73499e725aed0dd50f555
* Nano support for extensions and unknown fields.Gravatar Brian Duff2013-06-24
You can use the processor option store_unknown_fields to switch this support on: aprotoc --javanano_out=store_unknown_fields=true:/tmp/out A separate option for extensions isn't required. Support for unknown fields must be turned on to allow storing and retrieving extensions, because they are just stored as unknown fields. If unknown fields are switched on, extension related code will be generated when a proto message includes an extension range, or an extension is encountered. By default, store_unknown_fields is false. No additional code is generated, and the generator will error out if protos contain extension ranges or extensions. Change-Id: I1e034c9e8f3305612953f72438189a7da6ed2167