Revert https://codereview.chromium.org/1291903002 (protobuf roll).

third_party/protobuf/CHANGES.txt

Index: third_party/protobuf/CHANGES.txt
diff --git a/third_party/protobuf/CHANGES.txt b/third_party/protobuf/CHANGES.txt
index 846d735e6cda4f9c0aac77f3412bf92f3913be9e..a21e956c357e6171bc8a195e2d42b1c5c5b0f4dc 100644
--- a/third_party/protobuf/CHANGES.txt
+++ b/third_party/protobuf/CHANGES.txt
@@ -1,352 +1,4 @@
-2015-05-25 version 3.0.0-alpha-3 (Objective-C/C#):
-  General
-  * Introduced two new language implementations (Objective-C, C#) to proto3.
-  * Explicit "optional" keyword are disallowed in proto3 syntax, as fields are
-    optional by default.
-  * Group fields are no longer supported in proto3 syntax.
-  * Changed repeated primitive fields to use packed serialization by default in
-    proto3 (implemented for C++, Java, Python in this release).  The user can
-    still disable packed serialization by setting packed to false for now.
-  * Added well-known type protos (any.proto, empty.proto, timestamp.proto,
-    duration.proto, etc.). Users can import and use these protos just like
-    regular proto files. Addtional runtime support will be added for them in
-    future releases (in the form of utility helper functions, or having them
-    replaced by language specific types in generated code).
-  * Added a "reserved" keyword in both proto2 and proto3 syntax. User can use
-    this keyword to declare reserved field numbers and names to prevent them
-    from being reused by other fields in the same message.
-
-    To reserve field numbers, add a reserved declaration in your message:
-
-      message TestMessage {
-        reserved 2, 15, 9 to 11, 3;
-      }
-
-    This reserves field numbers 2, 3, 9, 10, 11 and 15. If a user uses any of
-    these as field numbers, the protocol buffer compiler will report an error.
-
-    Field names can also be reserved:
-
-      message TestMessage {
-        reserved "foo", "bar";
-      }
-
-  * Various bug fixes since 3.0.0-alpha-2
-
-  Objective-C
-    Objective-C includes a code generator and a native objective-c runtime
-    library.  By adding “--objc_out” to protoc, the code generator will generate
-    a header(*.pbobjc.h) and an implementation file(*.pbobjc.m) for each proto
-    file.
-
-    In this first release, the generated interface provides: enums, messages,
-    field support(single, repeated, map, oneof), proto2 and proto3 syntax
-    support, parsing and serialization. It’s  compatible with ARC and non-ARC
-    usage. Besides, user can also access it via the swift bridging header.
-
-    See objectivec/README.md for details.
-
-  C#
-    * C# protobufs are based on project
-      https://github.com/jskeet/protobuf-csharp-port. The original project was
-      frozen and all the new development will happen here.
-    * Codegen plugin for C# was completely rewritten to C++ and is now an
-      intergral part of protoc.
-    * Some refactorings and cleanup has been applied to the C# runtime library.
-    * Only proto2 is supported in C# at the moment, proto3 support is in
-      progress and will likely bring significant breaking changes to the API.
-
-    See csharp/README.md for details.
-
-  C++
-    * Added runtime support for Any type. To use Any in your proto file, first
-      import the definition of Any:
-
-        // foo.proto
-        import "google/protobuf/any.proto";
-        message Foo {
-          google.protobuf.Any any_field = 1;
-        }
-        message Bar {
-          int32 value = 1;
-        }
-
-      Then in C++ you can access the Any field using PackFrom()/UnpackTo()
-      methods:
-
-        Foo foo;
-        Bar bar = ...;
-        foo.mutable_any_field()->PackFrom(bar);
-        ...
-        if (foo.any_field().IsType<Bar>()) {
-          foo.any_field().UnpackTo(&bar);
-          ...
-        }
-    * In text format, entries of a map field will be sorted by key.
-
-  Java
-    * Continued optimizations on the lite runtime to improve performance for
-      Android.
-
-  Python
-    * Added map support.
-      - maps now have a dict-like interface (msg.map_field[key] = value)
-      - existing code that modifies maps via the repeated field interface
-        will need to be updated.
-
-  Ruby
-    * Improvements to RepeatedField's emulation of the Ruby Array API.
-    * Various speedups and internal cleanups.
-
-2015-02-26 version 3.0.0-alpha-2 (Python/Ruby/JavaNano):
-  General
-  * Introduced three new language implementations (Ruby, JavaNano, and
-    Python) to proto3.
-  * Various bug fixes since 3.0.0-alpha-1
-
-  Python:
-    Python has received several updates, most notably support for proto3
-    semantics in any .proto file that declares syntax="proto3".
-    Messages declared in proto3 files no longer represent field presence
-    for scalar fields (number, enums, booleans, or strings).  You can
-    no longer call HasField() for such fields, and they are serialized
-    based on whether they have a non-zero/empty/false value.
-
-    One other notable change is in the C++-accelerated implementation.
-    Descriptor objects (which describe the protobuf schema and allow
-    reflection over it) are no longer duplicated between the Python
-    and C++ layers.  The Python descriptors are now simple wrappers
-    around the C++ descriptors.  This change should significantly
-    reduce the memory usage of programs that use a lot of message
-    types.
-
-  Ruby:
-    We have added proto3 support for Ruby via a native C extension.
-
-    The Ruby extension itself is included in the ruby/ directory, and details on
-    building and installing the extension are in ruby/README.md. The extension
-    will also be published as a Ruby gem. Code generator support is included as
-    part of `protoc` with the `--ruby_out` flag.
-
-    The Ruby extension implements a user-friendly DSL to define message types
-    (also generated by the code generator from `.proto` files).  Once a message
-    type is defined, the user may create instances of the message that behave in
-    ways idiomatic to Ruby. For example:
-
-    - Message fields are present as ordinary Ruby properties (getter method
-      `foo` and setter method `foo=`).
-    - Repeated field elements are stored in a container that acts like a native
-      Ruby array, and map elements are stored in a container that acts like a
-      native Ruby hashmap.
-    - The usual well-known methods, such as `#to_s`, `#dup`, and the like, are
-      present.
-
-    Unlike several existing third-party Ruby extensions for protobuf, this
-    extension is built on a "strongly-typed" philosophy: message fields and
-    array/map containers will throw exceptions eagerly when values of the
-    incorrect type are inserted.
-
-    See ruby/README.md for details.
-
-  JavaNano:
-    JavaNano is a special code generator and runtime library designed especially
-    for resource-restricted systems, like Android. It is very resource-friendly
-    in both the amount of code and the runtime overhead. Here is an an overview
-    of JavaNano features compared with the official Java protobuf:
-
-    - No descriptors or message builders.
-    - All messages are mutable; fields are public Java fields.
-    - For optional fields only, encapsulation behind setter/getter/hazzer/
-      clearer functions is opt-in, which provide proper 'has' state support.
-    - For proto2, if not opted in, has state (field presence) is not available.
-      Serialization outputs all fields not equal to their defaults.
-      The behavior is consistent with proto3 semantics.
-    - Required fields (proto2 only) are always serialized.
-    - Enum constants are integers; protection against invalid values only
-      when parsing from the wire.
-    - Enum constants can be generated into container interfaces bearing
-      the enum's name (so the referencing code is in Java style).
-    - CodedInputByteBufferNano can only take byte[] (not InputStream).
-    - Similarly CodedOutputByteBufferNano can only write to byte[].
-    - Repeated fields are in arrays, not ArrayList or Vector. Null array
-      elements are allowed and silently ignored.
-    - Full support for serializing/deserializing repeated packed fields.
-    - Support  extensions (in proto2).
-    - Unset messages/groups are null, not an immutable empty default
-      instance.
-    - toByteArray(...) and mergeFrom(...) are now static functions of
-      MessageNano.
-    - The 'bytes' type translates to the Java type byte[].
-
-    See javanano/README.txt for details.
-
-2014-12-01 version 3.0.0-alpha-1 (C++/Java):
-
-  General
-  * Introduced Protocol Buffers language version 3 (aka proto3).
-
-    When protobuf was initially opensourced it implemented Protocol Buffers
-    language version 2 (aka proto2), which is why the version number
-    started from v2.0.0. From v3.0.0, a new language version (proto3) is
-    introduced while the old version (proto2) will continue to be supported.
-
-    The main intent of introducing proto3 is to clean up protobuf before
-    pushing the language as the foundation of Google's new API platform.
-    In proto3, the language is simplified, both for ease of use and  to
-    make it available in a wider range of programming languages. At the
-    same time a few features are added to better support common idioms
-    found in APIs.
-
-    The following are the main new features in language version 3:
-
-      1. Removal of field presence logic for primitive value fields, removal
-         of required fields, and removal of default values. This makes proto3
-         significantly easier to implement with open struct representations,
-         as in languages like Android Java, Objective C, or Go.
-      2. Removal of unknown fields.
-      3. Removal of extensions, which are instead replaced by a new standard
-         type called Any.
-      4. Fix semantics for unknown enum values.
-      5. Addition of maps.
-      6. Addition of a small set of standard types for representation of time,
-         dynamic data, etc.
-      7. A well-defined encoding in JSON as an alternative to binary proto
-         encoding.
-
-    This release (v3.0.0-alpha-1) includes partial proto3 support for C++ and
-    Java. Items 6 (well-known types) and 7 (JSON format) in the above feature
-    list are not impelmented.
-
-    A new notion "syntax" is introduced to specify whether a .proto file
-    uses proto2 or proto3:
-
-      // foo.proto
-      syntax = "proto3";
-      message Bar {...}
-
-    If omitted, the protocol compiler will generate a warning and "proto2" will
-    be used as the default. This warning will be turned into an error in a
-    future release.
-
-    We recommend that new Protocol Buffers users use proto3. However, we do not
-    generally recommend that existing users migrate from proto2 from proto3 due
-    to API incompatibility, and we will continue to support proto2 for a long
-    time.
-
-  * Added support for map fields (implemented in C++/Java for both proto2 and
-    proto3).
-
-    Map fields can be declared using the following syntax:
-
-      message Foo {
-        map<string, string> values = 1;
-      }
-
-    Data of a map field will be stored in memory as an unordered map and it
-    can be accessed through generated accessors.
-
-  C++
-  * Added arena allocation support (for both proto2 and proto3).
-
-    Profiling shows memory allocation and deallocation constitutes a significant
-    fraction of CPU-time spent in protobuf code and arena allocation is a
-    technique introduced to reduce this cost. With arena allocation, new
-    objects will be allocated from a large piece of preallocated memory and
-    deallocation of these objects is almost free. Early adoption shows 20% to
-    50% improvement in some Google binaries.
-
-    To enable arena support, add the following option to your .proto file:
-
-      option cc_enable_arenas = true;
-
-    Protocol compiler will generate additional code to make the generated
-    message classes work with arenas. This does not change the existing API
-    of protobuf messages and does not affect wire format. Your existing code
-    should continue to work after adding this option. In the future we will
-    make this option enabled by default.
-
-    To actually take advantage of arena allocation, you need to use the arena
-    APIs when creating messages. A quick example of using the arena API:
-
-      {
-        google::protobuf::Arena arena;
-        // Allocate a protobuf message in the arena.
-        MyMessage* message = Arena::CreateMessage<MyMessage>(&arena);
-        // All submessages will be allocated in the same arena.
-        if (!message->ParseFromString(data)) {
-          // Deal with malformed input data.
-        }
-        // Must not delete the message here. It will be deleted automatically
-        // when the arena is destroyed.
-      }
-
-    Currently arena does not work with map fields. Enabling arena in a .proto
-    file containing map fields will result in compile errors in the generated
-    code. This will be addressed in a future release.
-
-2014-10-20 version 2.6.1:
-
-  C++
-  * Added atomicops support for Solaris.
-  * Released memory allocated by InitializeDefaultRepeatedFields() and
-    GetEmptyString(). Some memory sanitizers reported them as memory leaks.
-
-  Java
-  * Updated DynamicMessage.setField() to handle repeated enum values
-    correctly.
-  * Fixed a bug that caused NullPointerException to be thrown when
-    converting manually constructed FileDescriptorProto to
-    FileDescriptor.
-
-  Python
-  * Fixed WhichOneof() to work with de-serialized protobuf messages.
-  * Fixed a missing file problem of Python C++ implementation.
-
-2014-08-15 version 2.6.0:
-
-  General
-  * Added oneofs(unions) feature. Fields in the same oneof will share
-    memory and at most one field can be set at the same time. Use the
-    oneof keyword to define a oneof like:
-      message SampleMessage {
-        oneof test_oneof {
-          string name = 4;
-          YourMessage sub_message = 9;
-        }
-      }
-  * Files, services, enums, messages, methods and enum values can be marked
-    as deprecated now.
-  * Added Support for list values, including lists of mesaages, when
-    parsing text-formatted protos in C++ and Java.
-      For example:  foo: [1, 2, 3]
-
-  C++
-  * Enhanced customization on TestFormat printing.
-  * Added SwapFields() in reflection API to swap a subset of fields.
-    Added SetAllocatedMessage() in reflection API.
-  * Repeated primitive extensions are now packable. The
-    [packed=true] option only affects serializers. Therefore, it is
-    possible to switch a repeated extension field to packed format
-    without breaking backwards-compatibility.
-  * Various speed optimizations.
-
-  Java
-  * writeTo() method in ByteString can now write a substring to an
-    output stream. Added endWith() method for ByteString.
-  * ByteString and ByteBuffer are now supported in CodedInputStream
-    and CodedOutputStream.
-  * java_generate_equals_and_hash can now be used with the LITE_RUNTIME.
-
-  Python
-  * A new C++-backed extension module (aka "cpp api v2") that replaces the
-    old ("cpp api v1") one.  Much faster than the pure Python code.  This one
-    resolves many bugs and is recommended for general use over the
-    pure Python when possible.
-  * Descriptors now have enum_types_by_name and extension_types_by_name dict
-    attributes.
-  * Support for Python 3.
-
-2013-02-27 version 2.5.0:
+2012-09-19 version 2.5.0:
 
   General
   * New notion "import public" that allows a proto file to forward the content
@@ -365,9 +17,6 @@
     be assigned the same numeric value. Default value is "true". Setting it to
     false causes the compiler to reject enum definitions where multiple symbols
     have the same numeric value.
-    Note: We plan to flip the default value to "false" in a future release.
-    Projects using enum aliases should set the option to "true" in their .proto
-    files.
 
   C++
   * New generated method set_allocated_foo(Type* foo) for message and string
@@ -383,7 +32,7 @@
     comments for corresponding classes and data members.
   * Added Parser to parse directly into messages without a Builder. For
     example,
-      Foo foo = Foo.PARSER.ParseFrom(input);
+      Foo foo = Foo.getParser().ParseFrom(input);
     Using Parser is ~25% faster than using Builder to parse messages.
   * Added getters/setters to access the underlying ByteString of a string field
     directly.