Package akka.protobuf

Class DescriptorProtos.SourceCodeInfo.Builder

    • Method Detail

      • 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
      • mergeFrom

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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