Package com.google.protobuf

Class DescriptorProtos.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;
        Specified by:
        getLocationOrBuilderList 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

      • 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

      • writeTo

        public void writeTo​(CodedOutputStream output)
             throws java.io.IOException
        Description copied from interface: MessageLite
        Serializes the message and writes it to output. This does not flush or close the stream.
        Specified by:
        writeTo in interface MessageLite
        Overrides:
        writeTo in class GeneratedMessage
        Throws:
        java.io.IOException

      • getSerializedSize

        public int getSerializedSize()
        Description copied from interface: MessageLite
        Get the number of bytes required to encode this message. The result is only computed on the first call and memoized after that. If this message requires more than Integer.MAX_VALUE bytes to encode, the return value will be smaller than the actual number of bytes required and might be negative.
        Specified by:
        getSerializedSize in interface MessageLite
        Overrides:
        getSerializedSize in class GeneratedMessage

      • equals

        public boolean equals​(java.lang.Object obj)
        Description copied from interface: Message
        Compares the specified object with this message for equality. Returns true if the given object is a message of the same type (as defined by getDescriptorForType()) and has identical values for all of its fields. Subclasses must implement this; inheriting Object.equals() is incorrect.
        Specified by:
        equals in interface Message
        Overrides:
        equals in class AbstractMessage
        Parameters:
        obj - object to be compared for equality with this message
        Returns:
        true if the specified object is equal to this message

      • hashCode

        public int hashCode()
        Description copied from interface: Message
        Returns the hash code value for this message. The hash code of a message should mix the message's type (object identity of the descriptor) with its contents (known and unknown field values). Subclasses must implement this; inheriting Object.hashCode() is incorrect.
        Specified by:
        hashCode in interface Message
        Overrides:
        hashCode in class AbstractMessage
        Returns:
        the hash code value for this message
        See Also:
        Map.hashCode()

      • 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