Class DescriptorProtos.SourceCodeInfo.Builder

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

public static final class DescriptorProtos.SourceCodeInfo.Builder extends GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder> implements DescriptorProtos.SourceCodeInfoOrBuilder
 Encapsulates information about the original source file from which a
 FileDescriptorProto was generated.
 
Protobuf type google.protobuf.SourceCodeInfo
  • Field Details

  • Constructor Details

  • Method Details

    • getDescriptor

      public static final Descriptors.Descriptor getDescriptor()
    • internalGetFieldAccessorTable

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

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

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

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

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

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

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

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

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

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

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

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

      Description copied from interface: Message.Builder
      Merge other into the message being built. other must have the exact same type as this (i.e. getDescriptorForType() == other.getDescriptorForType()).

      Merging occurs as follows. For each field:
      * For singular primitive fields, if the field is set in other, then other's value overwrites the value in this message.
      * For singular message fields, if the field is set in other, it is merged into the corresponding sub-message of this message using the same merging rules.
      * For repeated fields, the elements in other are concatenated with the elements in this message.
      * For oneof groups, if the other message has one of the fields set, the group of this message is cleared and replaced by the field of the other message, so that the oneof constraint is preserved.

      This is equivalent to the Message::MergeFrom method in C++.

      Specified by:
      mergeFrom in interface Message.Builder
      Overrides:
      mergeFrom in class AbstractMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>
    • mergeFrom

    • isInitialized

      public final boolean isInitialized()
      Description copied from interface: MessageLiteOrBuilder
      Returns true if all required fields in the message and all embedded messages are set, false otherwise.

      See also: MessageOrBuilder.getInitializationErrorString()

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

      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:
      IOException
    • ensureLocationIsMutable

      private void ensureLocationIsMutable()
    • 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

       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

       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

       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

       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

       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

       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

       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

       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

       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;
    • getLocationFieldBuilder

    • setUnknownFields

      public final DescriptorProtos.SourceCodeInfo.Builder setUnknownFields(UnknownFieldSet unknownFields)
      Description copied from interface: Message.Builder
      Set the UnknownFieldSet for this message.
      Specified by:
      setUnknownFields in interface Message.Builder
      Overrides:
      setUnknownFields in class GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
    • mergeUnknownFields

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