public static final class DescriptorProtos.SourceCodeInfo extends GeneratedMessageV3 implements DescriptorProtos.SourceCodeInfoOrBuilder
Encapsulates information about the original source file from which a
FileDescriptorProto was generated.
Protobuf type google.protobuf.SourceCodeInfo
Static Fields
LOCATION_FIELD_NUMBER
public static final int LOCATION_FIELD_NUMBER
| Field Value |
| Type |
Description |
int |
|
PARSER
public static final Parser<DescriptorProtos.SourceCodeInfo> PARSER
Static Methods
getDefaultInstance()
public static DescriptorProtos.SourceCodeInfo getDefaultInstance()
getDescriptor()
public static final Descriptors.Descriptor getDescriptor()
newBuilder()
public static DescriptorProtos.SourceCodeInfo.Builder newBuilder()
newBuilder(DescriptorProtos.SourceCodeInfo prototype)
public static DescriptorProtos.SourceCodeInfo.Builder newBuilder(DescriptorProtos.SourceCodeInfo prototype)
public static DescriptorProtos.SourceCodeInfo parseDelimitedFrom(InputStream input)
public static DescriptorProtos.SourceCodeInfo parseDelimitedFrom(InputStream input, ExtensionRegistryLite extensionRegistry)
parseFrom(byte[] data)
public static DescriptorProtos.SourceCodeInfo parseFrom(byte[] data)
| Parameter |
| Name |
Description |
data |
byte[]
|
parseFrom(byte[] data, ExtensionRegistryLite extensionRegistry)
public static DescriptorProtos.SourceCodeInfo parseFrom(byte[] data, ExtensionRegistryLite extensionRegistry)
parseFrom(ByteString data)
public static DescriptorProtos.SourceCodeInfo parseFrom(ByteString data)
parseFrom(ByteString data, ExtensionRegistryLite extensionRegistry)
public static DescriptorProtos.SourceCodeInfo parseFrom(ByteString data, ExtensionRegistryLite extensionRegistry)
public static DescriptorProtos.SourceCodeInfo parseFrom(CodedInputStream input)
public static DescriptorProtos.SourceCodeInfo parseFrom(CodedInputStream input, ExtensionRegistryLite extensionRegistry)
public static DescriptorProtos.SourceCodeInfo parseFrom(InputStream input)
public static DescriptorProtos.SourceCodeInfo parseFrom(InputStream input, ExtensionRegistryLite extensionRegistry)
parseFrom(ByteBuffer data)
public static DescriptorProtos.SourceCodeInfo parseFrom(ByteBuffer data)
parseFrom(ByteBuffer data, ExtensionRegistryLite extensionRegistry)
public static DescriptorProtos.SourceCodeInfo parseFrom(ByteBuffer data, ExtensionRegistryLite extensionRegistry)
parser()
public static Parser<DescriptorProtos.SourceCodeInfo> parser()
Methods
equals(Object obj)
public boolean equals(Object obj)
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.
| Parameter |
| Name |
Description |
obj |
Object
|
Overrides
getDefaultInstanceForType()
public DescriptorProtos.SourceCodeInfo getDefaultInstanceForType()
Get an instance of the type with no fields set. Because no fields are set, all getters for
singular fields will return default values and repeated fields will appear empty. This may or
may not be a singleton. This differs from the getDefaultInstance() method of generated
message classes in that this method is an abstract method of the MessageLite interface
whereas getDefaultInstance() is a static method of a specific class. They return the
same thing.
getLocation(int index)
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;
| Parameter |
| Name |
Description |
index |
int
|
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;
| Returns |
| Type |
Description |
int |
|
getLocationList()
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 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;
getLocationOrBuilder(int index)
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;
| Parameter |
| Name |
Description |
index |
int
|
getLocationOrBuilderList()
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 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;
| Returns |
| Type |
Description |
List<? extends com.google.protobuf.DescriptorProtos.SourceCodeInfo.LocationOrBuilder> |
|
getParserForType()
public Parser<DescriptorProtos.SourceCodeInfo> getParserForType()
Overrides
getSerializedSize()
public int getSerializedSize()
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.
| Returns |
| Type |
Description |
int |
|
Overrides
getUnknownFields()
public final UnknownFieldSet getUnknownFields()
Overrides
hashCode()
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.
| Returns |
| Type |
Description |
int |
|
Overrides
internalGetFieldAccessorTable()
protected GeneratedMessageV3.FieldAccessorTable internalGetFieldAccessorTable()
Get the FieldAccessorTable for this type. We can't have the message
class pass this in to the constructor because of bootstrapping trouble
with DescriptorProtos.
isInitialized()
public final boolean isInitialized()
Overrides
newBuilderForType()
public DescriptorProtos.SourceCodeInfo.Builder newBuilderForType()
newBuilderForType(GeneratedMessageV3.BuilderParent parent)
protected DescriptorProtos.SourceCodeInfo.Builder newBuilderForType(GeneratedMessageV3.BuilderParent parent)
TODO(xiaofeng): remove this together with GeneratedMessageV3.BuilderParent.
newInstance(GeneratedMessageV3.UnusedPrivateParameter unused)
protected Object newInstance(GeneratedMessageV3.UnusedPrivateParameter unused)
Creates a new instance of this message type. Overridden in the generated code.
| Returns |
| Type |
Description |
Object |
|
Overrides
toBuilder()
public DescriptorProtos.SourceCodeInfo.Builder toBuilder()
writeTo(CodedOutputStream output)
public void writeTo(CodedOutputStream output)
Serializes the message and writes it to output. This does not flush or close the
stream.
