Package com.google.protobuf
Class DescriptorProtos.SourceCodeInfo
- java.lang.Object
-
- com.google.protobuf.AbstractMessageLite<MessageType,BuilderType>
-
- com.google.protobuf.GeneratedMessageLite<DescriptorProtos.SourceCodeInfo,DescriptorProtos.SourceCodeInfo.Builder>
-
- com.google.protobuf.DescriptorProtos.SourceCodeInfo
-
- All Implemented Interfaces:
DescriptorProtos.SourceCodeInfoOrBuilder
,MessageLite
,MessageLiteOrBuilder
- Enclosing class:
- DescriptorProtos
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 typegoogle.protobuf.SourceCodeInfo
-
-
Nested Class Summary
Nested Classes Modifier and Type Class 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 typegoogle.protobuf.SourceCodeInfo.Location
static interface
DescriptorProtos.SourceCodeInfo.LocationOrBuilder
-
Nested classes/interfaces inherited from class com.google.protobuf.GeneratedMessageLite
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.ExtensionDescriptor, GeneratedMessageLite.GeneratedExtension<ContainingType extends MessageLite,Type>, GeneratedMessageLite.MethodToInvoke, GeneratedMessageLite.SerializedForm
-
Nested classes/interfaces inherited from class com.google.protobuf.AbstractMessageLite
AbstractMessageLite.InternalOneOfEnum
-
-
Field Summary
Fields Modifier and Type Field Description private static DescriptorProtos.SourceCodeInfo
DEFAULT_INSTANCE
private Internal.ProtobufList<DescriptorProtos.SourceCodeInfo.Location>
location_
static int
LOCATION_FIELD_NUMBER
private static Parser<DescriptorProtos.SourceCodeInfo>
PARSER
-
Fields inherited from class com.google.protobuf.GeneratedMessageLite
UNINITIALIZED_HASH_CODE, UNINITIALIZED_SERIALIZED_SIZE, unknownFields
-
Fields inherited from class com.google.protobuf.AbstractMessageLite
memoizedHashCode
-
-
Constructor Summary
Constructors Modifier Constructor Description private
SourceCodeInfo()
-
Method Summary
All Methods Static Methods Instance Methods Concrete Methods Modifier and Type Method Description 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.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.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.private void
clearLocation()
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.protected java.lang.Object
dynamicMethod(GeneratedMessageLite.MethodToInvoke method, java.lang.Object arg0, java.lang.Object arg1)
A method that implements different types of operations described inGeneratedMessageLite.MethodToInvoke
.private void
ensureLocationIsMutable()
static DescriptorProtos.SourceCodeInfo
getDefaultInstance()
DescriptorProtos.SourceCodeInfo.Location
getLocation(int index)
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.int
getLocationCount()
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.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.DescriptorProtos.SourceCodeInfo.LocationOrBuilder
getLocationOrBuilder(int index)
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.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.static DescriptorProtos.SourceCodeInfo.Builder
newBuilder()
static DescriptorProtos.SourceCodeInfo.Builder
newBuilder(DescriptorProtos.SourceCodeInfo prototype)
static DescriptorProtos.SourceCodeInfo
parseDelimitedFrom(java.io.InputStream input)
static DescriptorProtos.SourceCodeInfo
parseDelimitedFrom(java.io.InputStream input, ExtensionRegistryLite extensionRegistry)
static DescriptorProtos.SourceCodeInfo
parseFrom(byte[] data)
static DescriptorProtos.SourceCodeInfo
parseFrom(byte[] data, ExtensionRegistryLite extensionRegistry)
static DescriptorProtos.SourceCodeInfo
parseFrom(ByteString data)
static DescriptorProtos.SourceCodeInfo
parseFrom(ByteString data, ExtensionRegistryLite extensionRegistry)
static DescriptorProtos.SourceCodeInfo
parseFrom(CodedInputStream input)
static DescriptorProtos.SourceCodeInfo
parseFrom(CodedInputStream input, ExtensionRegistryLite extensionRegistry)
static DescriptorProtos.SourceCodeInfo
parseFrom(java.io.InputStream input)
static DescriptorProtos.SourceCodeInfo
parseFrom(java.io.InputStream input, ExtensionRegistryLite extensionRegistry)
static DescriptorProtos.SourceCodeInfo
parseFrom(java.nio.ByteBuffer data)
static DescriptorProtos.SourceCodeInfo
parseFrom(java.nio.ByteBuffer data, ExtensionRegistryLite extensionRegistry)
static Parser<DescriptorProtos.SourceCodeInfo>
parser()
private void
removeLocation(int index)
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.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.-
Methods inherited from class com.google.protobuf.GeneratedMessageLite
buildMessageInfo, clearMemoizedHashCode, clearMemoizedSerializedSize, computeHashCode, createBuilder, createBuilder, dynamicMethod, dynamicMethod, emptyBooleanList, emptyDoubleList, emptyFloatList, emptyIntList, emptyLongList, emptyProtobufList, equals, getDefaultInstance, getDefaultInstanceForType, getMemoizedHashCode, getMemoizedSerializedSize, getMethodOrDie, getParserForType, getSerializedSize, getSerializedSize, hashCode, hashCodeIsNotMemoized, invokeOrDie, isInitialized, isInitialized, isMutable, makeImmutable, markImmutable, mergeLengthDelimitedField, mergeUnknownFields, mergeVarintField, mutableCopy, mutableCopy, mutableCopy, mutableCopy, mutableCopy, mutableCopy, newBuilderForType, newMessageInfo, newMutableInstance, newRepeatedGeneratedExtension, newSingularGeneratedExtension, parseDelimitedFrom, parseDelimitedFrom, parseFrom, parseFrom, parseFrom, parseFrom, parseFrom, parseFrom, parseFrom, parseFrom, parseFrom, parseFrom, parsePartialFrom, parsePartialFrom, parseUnknownField, registerDefaultInstance, setMemoizedHashCode, setMemoizedSerializedSize, toBuilder, toString, writeTo
-
Methods inherited from class com.google.protobuf.AbstractMessageLite
addAll, checkByteStringIsUtf8, newUninitializedMessageException, toByteArray, toByteString, writeDelimitedTo, writeTo
-
Methods inherited from class java.lang.Object
clone, finalize, getClass, notify, notifyAll, wait, wait, wait
-
Methods inherited from interface com.google.protobuf.MessageLiteOrBuilder
getDefaultInstanceForType, isInitialized
-
-
-
-
Field Detail
-
LOCATION_FIELD_NUMBER
public static final int LOCATION_FIELD_NUMBER
- See Also:
- Constant Field Values
-
location_
private Internal.ProtobufList<DescriptorProtos.SourceCodeInfo.Location> location_
-
DEFAULT_INSTANCE
private static final DescriptorProtos.SourceCodeInfo DEFAULT_INSTANCE
-
PARSER
private static volatile Parser<DescriptorProtos.SourceCodeInfo> PARSER
-
-
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 interfaceDescriptorProtos.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 interfaceDescriptorProtos.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 interfaceDescriptorProtos.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.nio.ByteBuffer data) throws InvalidProtocolBufferException
- Throws:
InvalidProtocolBufferException
-
parseFrom
public static DescriptorProtos.SourceCodeInfo parseFrom(java.nio.ByteBuffer data, ExtensionRegistryLite extensionRegistry) throws InvalidProtocolBufferException
- Throws:
InvalidProtocolBufferException
-
parseFrom
public static DescriptorProtos.SourceCodeInfo parseFrom(ByteString data) throws InvalidProtocolBufferException
- Throws:
InvalidProtocolBufferException
-
parseFrom
public static DescriptorProtos.SourceCodeInfo parseFrom(ByteString data, ExtensionRegistryLite extensionRegistry) throws InvalidProtocolBufferException
- Throws:
InvalidProtocolBufferException
-
parseFrom
public static DescriptorProtos.SourceCodeInfo parseFrom(byte[] data) throws InvalidProtocolBufferException
- Throws:
InvalidProtocolBufferException
-
parseFrom
public static DescriptorProtos.SourceCodeInfo parseFrom(byte[] data, ExtensionRegistryLite extensionRegistry) throws InvalidProtocolBufferException
- Throws:
InvalidProtocolBufferException
-
parseFrom
public static DescriptorProtos.SourceCodeInfo parseFrom(java.io.InputStream input) throws java.io.IOException
- Throws:
java.io.IOException
-
parseFrom
public static DescriptorProtos.SourceCodeInfo parseFrom(java.io.InputStream input, ExtensionRegistryLite extensionRegistry) 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
-
parseDelimitedFrom
public static DescriptorProtos.SourceCodeInfo parseDelimitedFrom(java.io.InputStream input, ExtensionRegistryLite extensionRegistry) throws java.io.IOException
- Throws:
java.io.IOException
-
parseFrom
public static DescriptorProtos.SourceCodeInfo parseFrom(CodedInputStream input) throws java.io.IOException
- Throws:
java.io.IOException
-
parseFrom
public static DescriptorProtos.SourceCodeInfo parseFrom(CodedInputStream input, ExtensionRegistryLite extensionRegistry) throws java.io.IOException
- Throws:
java.io.IOException
-
newBuilder
public static DescriptorProtos.SourceCodeInfo.Builder newBuilder()
-
newBuilder
public static DescriptorProtos.SourceCodeInfo.Builder newBuilder(DescriptorProtos.SourceCodeInfo prototype)
-
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 inGeneratedMessageLite.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. SeeMAKE_IMMUTABLE
.IS_INITIALIZED
returnsnull
for false and the default instance for true. It doesn't use or modify any memoized value.GET_MEMOIZED_IS_INITIALIZED
returns the memoizedisInitialized
byte value.SET_MEMOIZED_IS_INITIALIZED
sets the memoizedisInitialized
byte value to 1 if the first parameter is not null, or to 0 if the first parameter is null.NEW_BUILDER
returns aBuilderType
instance.
For use by generated code only.
- Specified by:
dynamicMethod
in classGeneratedMessageLite<DescriptorProtos.SourceCodeInfo,DescriptorProtos.SourceCodeInfo.Builder>
-
getDefaultInstance
public static DescriptorProtos.SourceCodeInfo getDefaultInstance()
-
parser
public static Parser<DescriptorProtos.SourceCodeInfo> parser()
-
-