public static final class DescriptorProtos.SourceCodeInfo extends GeneratedMessageLite<DescriptorProtos.SourceCodeInfo,DescriptorProtos.SourceCodeInfo.Builder> implements DescriptorProtos.SourceCodeInfoOrBuilder
Encapsulates information about the original source file from which a FileDescriptorProto was generated.Protobuf type
google.protobuf.SourceCodeInfo
Modifier and Type | Class and Description |
---|---|
static class |
DescriptorProtos.SourceCodeInfo.Builder
Encapsulates information about the original source file from which a
FileDescriptorProto was generated.
|
static class |
DescriptorProtos.SourceCodeInfo.Location
Protobuf type
google.protobuf.SourceCodeInfo.Location |
static interface |
DescriptorProtos.SourceCodeInfo.LocationOrBuilder |
GeneratedMessageLite.DefaultInstanceBasedParser<T extends GeneratedMessageLite<T,?>>, GeneratedMessageLite.ExtendableBuilder<MessageType extends GeneratedMessageLite.ExtendableMessage<MessageType,BuilderType>,BuilderType extends GeneratedMessageLite.ExtendableBuilder<MessageType,BuilderType>>, GeneratedMessageLite.ExtendableMessage<MessageType extends GeneratedMessageLite.ExtendableMessage<MessageType,BuilderType>,BuilderType extends GeneratedMessageLite.ExtendableBuilder<MessageType,BuilderType>>, GeneratedMessageLite.ExtendableMessageOrBuilder<MessageType extends GeneratedMessageLite.ExtendableMessage<MessageType,BuilderType>,BuilderType extends GeneratedMessageLite.ExtendableBuilder<MessageType,BuilderType>>, GeneratedMessageLite.GeneratedExtension<ContainingType extends MessageLite,Type>, GeneratedMessageLite.MergeFromVisitor, GeneratedMessageLite.MethodToInvoke, GeneratedMessageLite.SerializedForm, GeneratedMessageLite.Visitor
Modifier and Type | Field and Description |
---|---|
static int |
LOCATION_FIELD_NUMBER |
memoizedSerializedSize, unknownFields
memoizedHashCode
dynamicMethod, dynamicMethod, emptyBooleanList, emptyDoubleList, emptyFloatList, emptyIntList, emptyLongList, emptyProtobufList, equals, getDefaultInstanceForType, getParserForType, hashCode, isInitialized, isInitialized, makeImmutable, makeImmutable, mergeLengthDelimitedField, mergeUnknownFields, mergeVarintField, mutableCopy, mutableCopy, mutableCopy, mutableCopy, mutableCopy, mutableCopy, newBuilderForType, newRepeatedGeneratedExtension, newSingularGeneratedExtension, parseDelimitedFrom, parseDelimitedFrom, parseFrom, parseFrom, parseFrom, parseFrom, parseFrom, parseFrom, parseFrom, parseFrom, parsePartialFrom, parseUnknownField, toBuilder, toString
addAll, checkByteStringIsUtf8, toByteArray, toByteString, writeDelimitedTo, writeTo
clone, finalize, getClass, notify, notifyAll, wait, wait, wait
getDefaultInstanceForType, isInitialized
public static final int LOCATION_FIELD_NUMBER
public List<DescriptorProtos.SourceCodeInfo.Location> getLocationList()
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition. This information is intended to be useful to IDEs, code indexers, documentation generators, and similar tools. For example, say we have a file like: message Foo { optional string foo = 1; } Let's look at just the field definition: optional string foo = 1; ^ ^^ ^^ ^ ^^^ a bc de f ghi We have the following locations: span path represents [a,i) [ 4, 0, 2, 0 ] The whole field definition. [a,b) [ 4, 0, 2, 0, 4 ] The label (optional). [c,d) [ 4, 0, 2, 0, 5 ] The type (string). [e,f) [ 4, 0, 2, 0, 1 ] The name (foo). [g,h) [ 4, 0, 2, 0, 3 ] The number (1). Notes: - A location may refer to a repeated field itself (i.e. not to any particular index within it). This is used whenever a set of elements are logically enclosed in a single code segment. For example, an entire extend block (possibly containing multiple extension definitions) will have an outer location whose path refers to the "extensions" repeated field without an index. - Multiple locations may have the same path. This happens when a single logical declaration is spread out across multiple places. The most obvious example is the "extend" block again -- there may be multiple extend blocks in the same scope, each of which will have the same path. - A location's span is not always a subset of its parent's span. For example, the "extendee" of an extension declaration appears at the beginning of the "extend" block and is shared by all extensions within the block. - Just because a location's span is a subset of some other location's span does not mean that it is a 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.
repeated .google.protobuf.SourceCodeInfo.Location location = 1;
getLocationList
in interface DescriptorProtos.SourceCodeInfoOrBuilder
public List<? extends DescriptorProtos.SourceCodeInfo.LocationOrBuilder> getLocationOrBuilderList()
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition. This information is intended to be useful to IDEs, code indexers, documentation generators, and similar tools. For example, say we have a file like: message Foo { optional string foo = 1; } Let's look at just the field definition: optional string foo = 1; ^ ^^ ^^ ^ ^^^ a bc de f ghi We have the following locations: span path represents [a,i) [ 4, 0, 2, 0 ] The whole field definition. [a,b) [ 4, 0, 2, 0, 4 ] The label (optional). [c,d) [ 4, 0, 2, 0, 5 ] The type (string). [e,f) [ 4, 0, 2, 0, 1 ] The name (foo). [g,h) [ 4, 0, 2, 0, 3 ] The number (1). Notes: - A location may refer to a repeated field itself (i.e. not to any particular index within it). This is used whenever a set of elements are logically enclosed in a single code segment. For example, an entire extend block (possibly containing multiple extension definitions) will have an outer location whose path refers to the "extensions" repeated field without an index. - Multiple locations may have the same path. This happens when a single logical declaration is spread out across multiple places. The most obvious example is the "extend" block again -- there may be multiple extend blocks in the same scope, each of which will have the same path. - A location's span is not always a subset of its parent's span. For example, the "extendee" of an extension declaration appears at the beginning of the "extend" block and is shared by all extensions within the block. - Just because a location's span is a subset of some other location's span does not mean that it is a 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.
repeated .google.protobuf.SourceCodeInfo.Location location = 1;
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 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.
repeated .google.protobuf.SourceCodeInfo.Location location = 1;
getLocationCount
in interface DescriptorProtos.SourceCodeInfoOrBuilder
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 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.
repeated .google.protobuf.SourceCodeInfo.Location location = 1;
getLocation
in interface DescriptorProtos.SourceCodeInfoOrBuilder
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 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.
repeated .google.protobuf.SourceCodeInfo.Location location = 1;
public void writeTo(CodedOutputStream output) throws IOException
MessageLite
output
. This does not
flush or close the stream.writeTo
in interface MessageLite
IOException
public int getSerializedSize()
MessageLite
getSerializedSize
in interface MessageLite
public static DescriptorProtos.SourceCodeInfo parseFrom(ByteString data) throws InvalidProtocolBufferException
InvalidProtocolBufferException
public static DescriptorProtos.SourceCodeInfo parseFrom(ByteString data, ExtensionRegistryLite extensionRegistry) throws InvalidProtocolBufferException
InvalidProtocolBufferException
public static DescriptorProtos.SourceCodeInfo parseFrom(byte[] data) throws InvalidProtocolBufferException
InvalidProtocolBufferException
public static DescriptorProtos.SourceCodeInfo parseFrom(byte[] data, ExtensionRegistryLite extensionRegistry) throws InvalidProtocolBufferException
InvalidProtocolBufferException
public static DescriptorProtos.SourceCodeInfo parseFrom(InputStream input) throws IOException
IOException
public static DescriptorProtos.SourceCodeInfo parseFrom(InputStream input, ExtensionRegistryLite extensionRegistry) throws IOException
IOException
public static DescriptorProtos.SourceCodeInfo parseDelimitedFrom(InputStream input) throws IOException
IOException
public static DescriptorProtos.SourceCodeInfo parseDelimitedFrom(InputStream input, ExtensionRegistryLite extensionRegistry) throws IOException
IOException
public static DescriptorProtos.SourceCodeInfo parseFrom(CodedInputStream input) throws IOException
IOException
public static DescriptorProtos.SourceCodeInfo parseFrom(CodedInputStream input, ExtensionRegistryLite extensionRegistry) throws IOException
IOException
public static DescriptorProtos.SourceCodeInfo.Builder newBuilder()
public static DescriptorProtos.SourceCodeInfo.Builder newBuilder(DescriptorProtos.SourceCodeInfo prototype)
protected final Object dynamicMethod(GeneratedMessageLite.MethodToInvoke method, Object arg0, Object arg1)
GeneratedMessageLite
GeneratedMessageLite.MethodToInvoke
.
Theses 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.
MERGE_FROM_STREAM
is parameterized with an CodedInputStream
and
ExtensionRegistryLite
. It consumes the input stream, parsing the contents into the
returned protocol buffer. If parsing throws an InvalidProtocolBufferException
, the
implementation wraps it in a RuntimeException.
NEW_INSTANCE
returns a new instance of the protocol buffer that has not yet been
made immutable. See MAKE_IMMUTABLE
.
IS_INITIALIZED
is parameterized with a Boolean
detailing whether to
memoize. It returns null
for false and the default instance for true. We optionally
memoize to support the Builder case, where memoization is not desired.
NEW_BUILDER
returns a BuilderType
instance.
VISIT
is parameterized with a Visitor
and a MessageType
and
recursively iterates through the fields side by side between this and the instance.
MAKE_IMMUTABLE
sets all internal fields to an immutable state.
For use by generated code only.
dynamicMethod
in class GeneratedMessageLite<DescriptorProtos.SourceCodeInfo,DescriptorProtos.SourceCodeInfo.Builder>
public static DescriptorProtos.SourceCodeInfo getDefaultInstance()
public static Parser<DescriptorProtos.SourceCodeInfo> parser()
Copyright © 2008–2016 Google. All rights reserved.