Class DescriptorProtos.SourceCodeInfo

    • Constructor Detail

      • SourceCodeInfo

        private SourceCodeInfo()
    • Method Detail

      • getLocationList

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

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

        private void ensureLocationIsMutable()
      • setLocation

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

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

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

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

        private void 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

        private void 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;
      • parseFrom

        public static DescriptorProtos.SourceCodeInfo parseFrom​(java.io.InputStream input)
                                                         throws java.io.IOException
        Throws:
        java.io.IOException
      • parseDelimitedFrom

        public static DescriptorProtos.SourceCodeInfo parseDelimitedFrom​(java.io.InputStream input)
                                                                  throws java.io.IOException
        Throws:
        java.io.IOException
      • dynamicMethod

        protected final java.lang.Object dynamicMethod​(GeneratedMessageLite.MethodToInvoke method,
                                                       java.lang.Object arg0,
                                                       java.lang.Object arg1)
        Description copied from class: GeneratedMessageLite
        A method that implements different types of operations described in GeneratedMessageLite.MethodToInvoke. These different kinds of operations are required to implement message-level operations for builders in the runtime. This method bundles those operations to reduce the generated methods count.
        • NEW_INSTANCE returns a new instance of the protocol buffer that has not yet been made immutable. See MAKE_IMMUTABLE.
        • IS_INITIALIZED returns null for false and the default instance for true. It doesn't use or modify any memoized value.
        • GET_MEMOIZED_IS_INITIALIZED returns the memoized isInitialized byte value.
        • SET_MEMOIZED_IS_INITIALIZED sets the memoized isInitialized byte value to 1 if the first parameter is not null, or to 0 if the first parameter is null.
        • NEW_BUILDER returns a BuilderType instance.
        This method, plus the implementation of the Builder, enables the Builder class to be proguarded away entirely on Android.

        For use by generated code only.

        Specified by:
        dynamicMethod in class GeneratedMessageLite<DescriptorProtos.SourceCodeInfo,​DescriptorProtos.SourceCodeInfo.Builder>