Class DescriptorProtos.SourceCodeInfo.Builder

java.lang.Object
com.google.protobuf.AbstractMessageLite.Builder
com.google.protobuf.AbstractMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>
com.google.protobuf.GeneratedMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>
com.google.protobuf.GeneratedMessage.ExtendableBuilder<DescriptorProtos.SourceCodeInfo,DescriptorProtos.SourceCodeInfo.Builder>
com.google.protobuf.generated.DescriptorProtos.SourceCodeInfo.Builder
All Implemented Interfaces:
DescriptorProtos.SourceCodeInfoOrBuilder, com.google.protobuf.GeneratedMessage.ExtendableMessageOrBuilder<DescriptorProtos.SourceCodeInfo>, com.google.protobuf.Message.Builder, com.google.protobuf.MessageLite.Builder, com.google.protobuf.MessageLiteOrBuilder, com.google.protobuf.MessageOrBuilder, Cloneable
Enclosing class:
DescriptorProtos.SourceCodeInfo
public static final class DescriptorProtos.SourceCodeInfo.Builder extends com.google.protobuf.GeneratedMessage.ExtendableBuilder<DescriptorProtos.SourceCodeInfo,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 Details

    • getDescriptor

      public static final com.google.protobuf.Descriptors.Descriptor getDescriptor()

    • internalGetFieldAccessorTable

      protected com.google.protobuf.GeneratedMessage.FieldAccessorTable internalGetFieldAccessorTable()
      Specified by:
      internalGetFieldAccessorTable in class com.google.protobuf.GeneratedMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>

    • clear

      public DescriptorProtos.SourceCodeInfo.Builder clear()
      Specified by:
      clear in interface com.google.protobuf.Message.Builder
      Specified by:
      clear in interface com.google.protobuf.MessageLite.Builder
      Overrides:
      clear in class com.google.protobuf.GeneratedMessage.ExtendableBuilder<DescriptorProtos.SourceCodeInfo,DescriptorProtos.SourceCodeInfo.Builder>

    • getDescriptorForType

      public com.google.protobuf.Descriptors.Descriptor getDescriptorForType()
      Specified by:
      getDescriptorForType in interface com.google.protobuf.Message.Builder
      Specified by:
      getDescriptorForType in interface com.google.protobuf.MessageOrBuilder
      Overrides:
      getDescriptorForType in class com.google.protobuf.GeneratedMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>

    • getDefaultInstanceForType

      public DescriptorProtos.SourceCodeInfo getDefaultInstanceForType()
      Specified by:
      getDefaultInstanceForType in interface com.google.protobuf.GeneratedMessage.ExtendableMessageOrBuilder<DescriptorProtos.SourceCodeInfo>
      Specified by:
      getDefaultInstanceForType in interface com.google.protobuf.MessageLiteOrBuilder
      Specified by:
      getDefaultInstanceForType in interface com.google.protobuf.MessageOrBuilder

    • build

      public DescriptorProtos.SourceCodeInfo build()
      Specified by:
      build in interface com.google.protobuf.Message.Builder
      Specified by:
      build in interface com.google.protobuf.MessageLite.Builder

    • buildPartial

      public DescriptorProtos.SourceCodeInfo buildPartial()
      Specified by:
      buildPartial in interface com.google.protobuf.Message.Builder
      Specified by:
      buildPartial in interface com.google.protobuf.MessageLite.Builder

    • mergeFrom

      public DescriptorProtos.SourceCodeInfo.Builder mergeFrom(com.google.protobuf.Message other)
      Specified by:
      mergeFrom in interface com.google.protobuf.Message.Builder
      Overrides:
      mergeFrom in class com.google.protobuf.AbstractMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>

    • mergeFrom

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

    • isInitialized

      public final boolean isInitialized()
      Specified by:
      isInitialized in interface com.google.protobuf.MessageLiteOrBuilder
      Overrides:
      isInitialized in class com.google.protobuf.GeneratedMessage.ExtendableBuilder<DescriptorProtos.SourceCodeInfo,DescriptorProtos.SourceCodeInfo.Builder>

    • mergeFrom

      public DescriptorProtos.SourceCodeInfo.Builder mergeFrom(com.google.protobuf.CodedInputStream input, com.google.protobuf.ExtensionRegistryLite extensionRegistry) throws IOException
      Specified by:
      mergeFrom in interface com.google.protobuf.Message.Builder
      Specified by:
      mergeFrom in interface com.google.protobuf.MessageLite.Builder
      Overrides:
      mergeFrom in class com.google.protobuf.AbstractMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>
      Throws:
      IOException

    • getLocationList

      public 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 descendant.  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 descendant.  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 descendant.  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 descendant.  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 descendant.  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 descendant.  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 descendant.  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 descendant.  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 descendant.  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(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 descendant.  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 descendant.  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 descendant.  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 descendant.  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 descendant.  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 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 descendant.  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 descendant.  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 descendant.  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 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 descendant.  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;