DescriptorProtos.SourceCodeInfo.Builder
Date: 2017-07-08

com.google.protobuf

## Class DescriptorProtos.SourceCodeInfo.Builder

- java.lang.Object
- - com.google.protobuf.AbstractMessageLite.Builder
  - - com.google.protobuf.AbstractMessage.Builder<BuilderType>
    - - com.google.protobuf.GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
      - - com.google.protobuf.DescriptorProtos.SourceCodeInfo.Builder

- All Implemented Interfaces:
    DescriptorProtos.SourceCodeInfoOrBuilder, Message.Builder, MessageLite.Builder, MessageLiteOrBuilder, MessageOrBuilder, java.lang.Cloneable
  Enclosing class:
    DescriptorProtos.SourceCodeInfo

      public static final class DescriptorProtos.SourceCodeInfo.Builder
      extends GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
      implements DescriptorProtos.SourceCodeInfoOrBuilder

       Encapsulates information about the original source file from which a
       FileDescriptorProto was generated.

  Protobuf type `google.protobuf.SourceCodeInfo`

- - ### Method Summary

    Methods
    Modifier and Type | Method and Description
    --- | ---
    `DescriptorProtos.SourceCodeInfo.Builder` | `addAllLocation(java.lang.Iterable<? extends DescriptorProtos.SourceCodeInfo.Location> values)` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `DescriptorProtos.SourceCodeInfo.Builder` | `addLocation(DescriptorProtos.SourceCodeInfo.Location.Builder builderForValue)` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `DescriptorProtos.SourceCodeInfo.Builder` | `addLocation(DescriptorProtos.SourceCodeInfo.Location value)` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `DescriptorProtos.SourceCodeInfo.Builder` | `addLocation(int index, DescriptorProtos.SourceCodeInfo.Location.Builder builderForValue)` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `DescriptorProtos.SourceCodeInfo.Builder` | `addLocation(int index, DescriptorProtos.SourceCodeInfo.Location value)` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `DescriptorProtos.SourceCodeInfo.Location.Builder` | `addLocationBuilder()` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `DescriptorProtos.SourceCodeInfo.Location.Builder` | `addLocationBuilder(int index)` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `DescriptorProtos.SourceCodeInfo.Builder` | `addRepeatedField(Descriptors.FieldDescriptor field, java.lang.Object value)` Like `setRepeatedField`, but appends the value as a new element.
    `DescriptorProtos.SourceCodeInfo` | `build()` Constructs the message based on the state of the Builder.
    `DescriptorProtos.SourceCodeInfo` | `buildPartial()` Like `MessageLite.Builder.build()`, but does not throw an exception if the message is missing required fields.
    `DescriptorProtos.SourceCodeInfo.Builder` | `clear()` Called by the initialization and clear code paths to allow subclasses to reset any of their builtin fields back to the initial values.
    `DescriptorProtos.SourceCodeInfo.Builder` | `clearField(Descriptors.FieldDescriptor field)` Clears the field.
    `DescriptorProtos.SourceCodeInfo.Builder` | `clearLocation()` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `DescriptorProtos.SourceCodeInfo.Builder` | `clearOneof(Descriptors.OneofDescriptor oneof)` TODO(jieluo): Clear it when all subclasses have implemented this method.
    `DescriptorProtos.SourceCodeInfo.Builder` | `clone()` Clones the Builder.
    `DescriptorProtos.SourceCodeInfo` | `getDefaultInstanceForType()` Get an instance of the type with no fields set.
    `static Descriptors.Descriptor` | `getDescriptor()`
    `Descriptors.Descriptor` | `getDescriptorForType()` Get the message's type's descriptor.
    `DescriptorProtos.SourceCodeInfo.Location` | `getLocation(int index)` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `DescriptorProtos.SourceCodeInfo.Location.Builder` | `getLocationBuilder(int index)` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `java.util.List<DescriptorProtos.SourceCodeInfo.Location.Builder>` | `getLocationBuilderList()` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `int` | `getLocationCount()` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `java.util.List<DescriptorProtos.SourceCodeInfo.Location>` | `getLocationList()` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `DescriptorProtos.SourceCodeInfo.LocationOrBuilder` | `getLocationOrBuilder(int index)` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `java.util.List<? extends DescriptorProtos.SourceCodeInfo.LocationOrBuilder>` | `getLocationOrBuilderList()` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `protected GeneratedMessageV3.FieldAccessorTable` | `internalGetFieldAccessorTable()` Get the FieldAccessorTable for this type.
    `boolean` | `isInitialized()` Returns true if all required fields in the message and all embedded messages are set, false otherwise.
    `DescriptorProtos.SourceCodeInfo.Builder` | `mergeFrom(CodedInputStream input, ExtensionRegistryLite extensionRegistry)` Like `MessageLite.Builder.mergeFrom(CodedInputStream)`, but also parses extensions.
    `DescriptorProtos.SourceCodeInfo.Builder` | `mergeFrom(DescriptorProtos.SourceCodeInfo other)`
    `DescriptorProtos.SourceCodeInfo.Builder` | `mergeFrom(Message other)` Merge `other` into the message being built.
    `DescriptorProtos.SourceCodeInfo.Builder` | `mergeUnknownFields(UnknownFieldSet unknownFields)` Merge some unknown fields into the `UnknownFieldSet` for this message.
    `DescriptorProtos.SourceCodeInfo.Builder` | `removeLocation(int index)` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `DescriptorProtos.SourceCodeInfo.Builder` | `setField(Descriptors.FieldDescriptor field, java.lang.Object value)` Sets a field to the given value.
    `DescriptorProtos.SourceCodeInfo.Builder` | `setLocation(int index, DescriptorProtos.SourceCodeInfo.Location.Builder builderForValue)` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `DescriptorProtos.SourceCodeInfo.Builder` | `setLocation(int index, DescriptorProtos.SourceCodeInfo.Location value)` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `DescriptorProtos.SourceCodeInfo.Builder` | `setRepeatedField(Descriptors.FieldDescriptor field, int index, java.lang.Object value)` Sets an element of a repeated field to the given value.
    `DescriptorProtos.SourceCodeInfo.Builder` | `setUnknownFields(UnknownFieldSet unknownFields)` Set the `UnknownFieldSet` for this message.

    - ### Methods inherited from class com.google.protobuf.GeneratedMessageV3.Builder

      `getAllFields, getField, getFieldBuilder, getOneofFieldDescriptor, getParentForChildren, getRepeatedField, getRepeatedFieldBuilder, getRepeatedFieldCount, getUnknownFields, hasField, hasOneof, internalGetMapField, internalGetMutableMapField, isClean, markClean, newBuilderForField, onBuilt, onChanged, parseUnknownField`

    - ### Methods inherited from class com.google.protobuf.AbstractMessage.Builder

      `findInitializationErrors, getInitializationErrorString, internalMergeFrom, mergeDelimitedFrom, mergeDelimitedFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, newUninitializedMessageException, toString`

    - ### Methods inherited from class com.google.protobuf.AbstractMessageLite.Builder

      `addAll, mergeFrom, newUninitializedMessageException`

    - ### Methods inherited from class java.lang.Object

      `equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait`

    - ### Methods inherited from interface com.google.protobuf.MessageOrBuilder

      `findInitializationErrors, getAllFields, getField, getInitializationErrorString, getOneofFieldDescriptor, getRepeatedField, getRepeatedFieldCount, getUnknownFields, hasField, hasOneof`

    - ### Methods inherited from interface com.google.protobuf.MessageLite.Builder

      `mergeFrom`

- - ### Method Detail

    - #### getDescriptor

          public static final Descriptors.Descriptor getDescriptor()

    - #### internalGetFieldAccessorTable

          protected GeneratedMessageV3.FieldAccessorTable internalGetFieldAccessorTable()

      Description copied from class: `GeneratedMessageV3.Builder`
      Get the FieldAccessorTable for this type. We can't have the message class pass this in to the constructor because of bootstrapping trouble with DescriptorProtos.
      Specified by:
        `internalGetFieldAccessorTable` in class `GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>`

    - #### clear

          public DescriptorProtos.SourceCodeInfo.Builder clear()

      Description copied from class: `GeneratedMessageV3.Builder`
      Called by the initialization and clear code paths to allow subclasses to reset any of their builtin fields back to the initial values.
      Specified by:
        `clear` in interface `Message.Builder`
      Specified by:
        `clear` in interface `MessageLite.Builder`
      Overrides:
        `clear` in class `GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>`

    - #### getDescriptorForType

          public Descriptors.Descriptor getDescriptorForType()

      Description copied from interface: `Message.Builder`
      Get the message's type's descriptor. See `MessageOrBuilder.getDescriptorForType()`.
      Specified by:
        `getDescriptorForType` in interface `Message.Builder`
      Specified by:
        `getDescriptorForType` in interface `MessageOrBuilder`
      Overrides:
        `getDescriptorForType` in class `GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>`

    - #### getDefaultInstanceForType

          public DescriptorProtos.SourceCodeInfo getDefaultInstanceForType()

      Description copied from interface: `MessageLiteOrBuilder`
      Get an instance of the type with no fields set. Because no fields are set, all getters for singular fields will return default values and repeated fields will appear empty. This may or may not be a singleton. This differs from the `getDefaultInstance()` method of generated message classes in that this method is an abstract method of the `MessageLite` interface whereas `getDefaultInstance()` is a static method of a specific class. They return the same thing.
      Specified by:
        `getDefaultInstanceForType` in interface `MessageLiteOrBuilder`
      Specified by:
        `getDefaultInstanceForType` in interface `MessageOrBuilder`

    - #### build

          public DescriptorProtos.SourceCodeInfo build()

      Description copied from interface: `MessageLite.Builder`
      Constructs the message based on the state of the Builder. Subsequent changes to the Builder will not affect the returned message.
      Specified by:
        `build` in interface `Message.Builder`
      Specified by:
        `build` in interface `MessageLite.Builder`

    - #### buildPartial

          public DescriptorProtos.SourceCodeInfo buildPartial()

      Description copied from interface: `MessageLite.Builder`
      Like `MessageLite.Builder.build()`, but does not throw an exception if the message is missing required fields. Instead, a partial message is returned. Subsequent changes to the Builder will not affect the returned message.
      Specified by:
        `buildPartial` in interface `Message.Builder`
      Specified by:
        `buildPartial` in interface `MessageLite.Builder`

    - #### clone

          public DescriptorProtos.SourceCodeInfo.Builder clone()

      Description copied from interface: `MessageLite.Builder`
      Clones the Builder.
      Specified by:
        `clone` in interface `Message.Builder`
      Specified by:
        `clone` in interface `MessageLite.Builder`
      Overrides:
        `clone` in class `GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>`
      See Also:
        `Object.clone()`

    - #### setField

          public DescriptorProtos.SourceCodeInfo.Builder setField(Descriptors.FieldDescriptor field,
                                                         java.lang.Object value)

      Description copied from interface: `Message.Builder`
      Sets a field to the given value. The value must be of the correct type for this field, i.e. the same type that `MessageOrBuilder.getField(Descriptors.FieldDescriptor)` would return.
      Specified by:
        `setField` in interface `Message.Builder`
      Overrides:
        `setField` in class `GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>`

    - #### clearField

          public DescriptorProtos.SourceCodeInfo.Builder clearField(Descriptors.FieldDescriptor field)

      Description copied from interface: `Message.Builder`
      Clears the field. This is exactly equivalent to calling the generated "clear" accessor method corresponding to the field.
      Specified by:
        `clearField` in interface `Message.Builder`
      Overrides:
        `clearField` in class `GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>`

    - #### clearOneof

          public DescriptorProtos.SourceCodeInfo.Builder clearOneof(Descriptors.OneofDescriptor oneof)

      Description copied from class: `AbstractMessage.Builder`
      TODO(jieluo): Clear it when all subclasses have implemented this method.
      Specified by:
        `clearOneof` in interface `Message.Builder`
      Overrides:
        `clearOneof` in class `GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>`

    - #### setRepeatedField

          public DescriptorProtos.SourceCodeInfo.Builder setRepeatedField(Descriptors.FieldDescriptor field,
                                                                 int index,
                                                                 java.lang.Object value)

      Description copied from interface: `Message.Builder`
      Sets an element of a repeated field to the given value. The value must be of the correct type for this field, i.e. the same type that `MessageOrBuilder.getRepeatedField(Descriptors.FieldDescriptor,int)` would return.
      Specified by:
        `setRepeatedField` in interface `Message.Builder`
      Overrides:
        `setRepeatedField` in class `GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>`

    - #### addRepeatedField

          public DescriptorProtos.SourceCodeInfo.Builder addRepeatedField(Descriptors.FieldDescriptor field,
                                                                 java.lang.Object value)

      Description copied from interface: `Message.Builder`
      Like `setRepeatedField`, but appends the value as a new element.
      Specified by:
        `addRepeatedField` in interface `Message.Builder`
      Overrides:
        `addRepeatedField` in class `GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>`

    - #### mergeFrom

          public DescriptorProtos.SourceCodeInfo.Builder mergeFrom(Message other)

      Description copied from interface: `Message.Builder`
      Merge `other` into the message being built. `other` must have the exact same type as `this` (i.e. `getDescriptorForType() == other.getDescriptorForType()`). Merging occurs as follows. For each field:
      * For singular primitive fields, if the field is set in `other`, then `other`'s value overwrites the value in this message.
      * For singular message fields, if the field is set in `other`, it is merged into the corresponding sub-message of this message using the same merging rules.
      * For repeated fields, the elements in `other` are concatenated with the elements in this message. * For oneof groups, if the other message has one of the fields set, the group of this message is cleared and replaced by the field of the other message, so that the oneof constraint is preserved. This is equivalent to the `Message::MergeFrom` method in C++.
      Specified by:
        `mergeFrom` in interface `Message.Builder`
      Overrides:
        `mergeFrom` in class `AbstractMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>`

    - #### mergeFrom

          public DescriptorProtos.SourceCodeInfo.Builder mergeFrom(DescriptorProtos.SourceCodeInfo other)

    - #### isInitialized

          public final boolean isInitialized()

      Description copied from interface: `MessageLiteOrBuilder`
      Returns true if all required fields in the message and all embedded messages are set, false otherwise.

      See also: `MessageOrBuilder.getInitializationErrorString()`

      Specified by:
        `isInitialized` in interface `MessageLiteOrBuilder`
      Overrides:
        `isInitialized` in class `GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>`

    - #### mergeFrom

          public DescriptorProtos.SourceCodeInfo.Builder mergeFrom(CodedInputStream input,
                                                          ExtensionRegistryLite extensionRegistry)
                                                            throws java.io.IOException

      Description copied from interface: `MessageLite.Builder`
      Like `MessageLite.Builder.mergeFrom(CodedInputStream)`, but also parses extensions. The extensions that you want to be able to parse must be registered in `extensionRegistry`. Extensions not in the registry will be treated as unknown fields.
      Specified by:
        `mergeFrom` in interface `Message.Builder`
      Specified by:
        `mergeFrom` in interface `MessageLite.Builder`
      Overrides:
        `mergeFrom` in class `AbstractMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>`
      Throws:
        `java.io.IOException`

    - #### getLocationList

          public java.util.List<DescriptorProtos.SourceCodeInfo.Location> getLocationList()

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
      Specified by:
        `getLocationList` in interface `DescriptorProtos.SourceCodeInfoOrBuilder`

    - #### getLocationCount

          public int getLocationCount()

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
      Specified by:
        `getLocationCount` in interface `DescriptorProtos.SourceCodeInfoOrBuilder`

    - #### getLocation

          public DescriptorProtos.SourceCodeInfo.Location getLocation(int index)

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
      Specified by:
        `getLocation` in interface `DescriptorProtos.SourceCodeInfoOrBuilder`

    - #### setLocation

          public DescriptorProtos.SourceCodeInfo.Builder setLocation(int index,
                                                            DescriptorProtos.SourceCodeInfo.Location value)

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

    - #### setLocation

          public DescriptorProtos.SourceCodeInfo.Builder setLocation(int index,
                                                            DescriptorProtos.SourceCodeInfo.Location.Builder builderForValue)

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

    - #### addLocation

          public DescriptorProtos.SourceCodeInfo.Builder addLocation(DescriptorProtos.SourceCodeInfo.Location value)

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

    - #### addLocation

          public DescriptorProtos.SourceCodeInfo.Builder addLocation(int index,
                                                            DescriptorProtos.SourceCodeInfo.Location value)

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

    - #### addLocation

          public DescriptorProtos.SourceCodeInfo.Builder addLocation(DescriptorProtos.SourceCodeInfo.Location.Builder builderForValue)

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

    - #### addLocation

          public DescriptorProtos.SourceCodeInfo.Builder addLocation(int index,
                                                            DescriptorProtos.SourceCodeInfo.Location.Builder builderForValue)

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

    - #### addAllLocation

          public DescriptorProtos.SourceCodeInfo.Builder addAllLocation(java.lang.Iterable<? extends DescriptorProtos.SourceCodeInfo.Location> values)

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

    - #### clearLocation

          public DescriptorProtos.SourceCodeInfo.Builder clearLocation()

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

    - #### removeLocation

          public DescriptorProtos.SourceCodeInfo.Builder removeLocation(int index)

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

    - #### getLocationBuilder

          public DescriptorProtos.SourceCodeInfo.Location.Builder getLocationBuilder(int index)

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

    - #### getLocationOrBuilder

          public DescriptorProtos.SourceCodeInfo.LocationOrBuilder getLocationOrBuilder(int index)

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
      Specified by:
        `getLocationOrBuilder` in interface `DescriptorProtos.SourceCodeInfoOrBuilder`

    - #### getLocationOrBuilderList

          public java.util.List<? extends DescriptorProtos.SourceCodeInfo.LocationOrBuilder> getLocationOrBuilderList()

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
      Specified by:
        `getLocationOrBuilderList` in interface `DescriptorProtos.SourceCodeInfoOrBuilder`

    - #### addLocationBuilder

          public DescriptorProtos.SourceCodeInfo.Location.Builder addLocationBuilder()

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

    - #### addLocationBuilder

          public DescriptorProtos.SourceCodeInfo.Location.Builder addLocationBuilder(int index)

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

    - #### getLocationBuilderList

          public java.util.List<DescriptorProtos.SourceCodeInfo.Location.Builder> getLocationBuilderList()

           A Location identifies a piece of source code in a .proto file which
           corresponds to a particular definition.  This information is intended
           to be useful to IDEs, code indexers, documentation generators, and similar
           tools.
           For example, say we have a file like:
             message Foo {
               optional string foo = 1;
             }
           Let's look at just the field definition:
             optional string foo = 1;
             ^       ^^     ^^  ^  ^^^
             a       bc     de  f  ghi
           We have the following locations:
             span   path               represents
             [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
             [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
             [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
             [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
             [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
           Notes:
           - A location may refer to a repeated field itself (i.e. not to any
             particular index within it).  This is used whenever a set of elements are
             logically enclosed in a single code segment.  For example, an entire
             extend block (possibly containing multiple extension definitions) will
             have an outer location whose path refers to the "extensions" repeated
             field without an index.
           - Multiple locations may have the same path.  This happens when a single
             logical declaration is spread out across multiple places.  The most
             obvious example is the "extend" block again -- there may be multiple
             extend blocks in the same scope, each of which will have the same path.
           - A location's span is not always a subset of its parent's span.  For
             example, the "extendee" of an extension declaration appears at the
             beginning of the "extend" block and is shared by all extensions within
             the block.
           - Just because a location's span is a subset of some other location's span
             does not mean that it is a descendent.  For example, a "group" defines
             both a type and a field in a single declaration.  Thus, the locations
             corresponding to the type and field and their components will overlap.
           - Code which tries to interpret locations should probably be designed to
             ignore those that it doesn't understand, as more types of locations could
             be recorded in the future.

      `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

    - #### setUnknownFields

          public final DescriptorProtos.SourceCodeInfo.Builder setUnknownFields(UnknownFieldSet unknownFields)

      Description copied from interface: `Message.Builder`
      Set the `UnknownFieldSet` for this message.
      Specified by:
        `setUnknownFields` in interface `Message.Builder`
      Overrides:
        `setUnknownFields` in class `GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>`

    - #### mergeUnknownFields

          public final DescriptorProtos.SourceCodeInfo.Builder mergeUnknownFields(UnknownFieldSet unknownFields)

      Description copied from interface: `Message.Builder`
      Merge some unknown fields into the `UnknownFieldSet` for this message.
      Specified by:
        `mergeUnknownFields` in interface `Message.Builder`
      Overrides:
        `mergeUnknownFields` in class `GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>`