Package com.google.protobuf

## Class DescriptorProtos.SourceCodeInfo.Builder

- java.lang.Object
- - com.google.protobuf.AbstractMessageLite.Builder<BuilderType>
  - - com.google.protobuf.AbstractMessage.Builder<BuilderType>
    - - com.google.protobuf.GeneratedMessage.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 GeneratedMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>
    implements DescriptorProtos.SourceCodeInfoOrBuilder

Protobuf type `google.protobuf.SourceCodeInfo`

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

### Method Summary

All Methods Static Methods Instance Methods Concrete Methods
`DescriptorProtos.SourceCodeInfo.Builder` `addAllLocation​(java.lang.Iterable<? extends DescriptorProtos.SourceCodeInfo.Location> values)` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`DescriptorProtos.SourceCodeInfo.Builder` `addLocation​(int index, DescriptorProtos.SourceCodeInfo.Location value)` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`DescriptorProtos.SourceCodeInfo.Builder` `addLocation​(int index, DescriptorProtos.SourceCodeInfo.Location.Builder builderForValue)` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`DescriptorProtos.SourceCodeInfo.Builder` `addLocation​(DescriptorProtos.SourceCodeInfo.Location value)` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`DescriptorProtos.SourceCodeInfo.Builder` `addLocation​(DescriptorProtos.SourceCodeInfo.Location.Builder builderForValue)` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`DescriptorProtos.SourceCodeInfo.Location.Builder` `addLocationBuilder()` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`DescriptorProtos.SourceCodeInfo.Location.Builder` `addLocationBuilder​(int index)` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`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` `clearLocation()` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`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)` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`DescriptorProtos.SourceCodeInfo.Location.Builder` `getLocationBuilder​(int index)` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`java.util.List<DescriptorProtos.SourceCodeInfo.Location.Builder>` `getLocationBuilderList()` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`int` `getLocationCount()` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`java.util.List<DescriptorProtos.SourceCodeInfo.Location>` `getLocationList()` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`DescriptorProtos.SourceCodeInfo.LocationOrBuilder` `getLocationOrBuilder​(int index)` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`java.util.List<? extends DescriptorProtos.SourceCodeInfo.LocationOrBuilder>` `getLocationOrBuilderList()` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`protected GeneratedMessage.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` `removeLocation​(int index)` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`DescriptorProtos.SourceCodeInfo.Builder` `setLocation​(int index, DescriptorProtos.SourceCodeInfo.Location value)` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`DescriptorProtos.SourceCodeInfo.Builder` `setLocation​(int index, DescriptorProtos.SourceCodeInfo.Location.Builder builderForValue)` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

### Methods inherited from class com.google.protobuf.GeneratedMessage.Builder

`addRepeatedField, clearField, clearOneof, getAllFields, getField, getFieldBuilder, getOneofFieldDescriptor, getParentForChildren, getRepeatedField, getRepeatedFieldCount, getUnknownFields, hasField, hasOneof, isClean, markClean, mergeUnknownFields, newBuilderForField, onBuilt, onChanged, parseUnknownField, setField, setRepeatedField, setUnknownFields`

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

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

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

`addAll, 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`

### Method Detail

#### getDescriptor

    public static final Descriptors.Descriptor getDescriptor()

#### internalGetFieldAccessorTable

    protected GeneratedMessage.FieldAccessorTable internalGetFieldAccessorTable()

Description copied from class: `GeneratedMessage.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 `GeneratedMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>`

#### clear

    public DescriptorProtos.SourceCodeInfo.Builder clear()

Description copied from class: `GeneratedMessage.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 `GeneratedMessage.Builder<DescriptorProtos.SourceCodeInfo.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 `GeneratedMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>`
See Also:
  `Object.clone()`

#### 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 `GeneratedMessage.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`

#### 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. 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 `GeneratedMessage.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()

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

     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.

Specified by:
  `getLocationList` in interface `DescriptorProtos.SourceCodeInfoOrBuilder`

#### getLocationCount

    public int getLocationCount()

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

     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.

Specified by:
  `getLocationCount` in interface `DescriptorProtos.SourceCodeInfoOrBuilder`

#### getLocation

    public DescriptorProtos.SourceCodeInfo.Location getLocation​(int index)

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

     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.

Specified by:
  `getLocation` in interface `DescriptorProtos.SourceCodeInfoOrBuilder`

#### setLocation

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

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

     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.

#### setLocation

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

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

     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.

#### addLocation

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

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

     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.

#### addLocation

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

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

     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.

#### addLocation

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

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

     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.

#### addLocation

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

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

     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.

#### addAllLocation

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

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

     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.

#### clearLocation

    public DescriptorProtos.SourceCodeInfo.Builder clearLocation()

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

     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.

#### removeLocation

    public DescriptorProtos.SourceCodeInfo.Builder removeLocation​(int index)

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

     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.

#### getLocationBuilder

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

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

     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.

#### getLocationOrBuilder

    public DescriptorProtos.SourceCodeInfo.LocationOrBuilder getLocationOrBuilder​(int index)

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

     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.

Specified by:
  `getLocationOrBuilder` in interface `DescriptorProtos.SourceCodeInfoOrBuilder`

#### getLocationOrBuilderList

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

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

     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.

Specified by:
  `getLocationOrBuilderList` in interface `DescriptorProtos.SourceCodeInfoOrBuilder`

#### addLocationBuilder

    public DescriptorProtos.SourceCodeInfo.Location.Builder addLocationBuilder()

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

     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.

#### addLocationBuilder

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

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

     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.

#### getLocationBuilderList

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

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

     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.