public static final class DescriptorProtos.SourceCodeInfo.Builder extends GeneratedMessageV3.Builder<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 | Method and Description |
|---|---|
DescriptorProtos.SourceCodeInfo.Builder |
addAllLocation(Iterable<? extends DescriptorProtos.SourceCodeInfo.Location> values)
A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.
|
DescriptorProtos.SourceCodeInfo.Builder |
addLocation(DescriptorProtos.SourceCodeInfo.Location.Builder builderForValue)
A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.
|
DescriptorProtos.SourceCodeInfo.Builder |
addLocation(DescriptorProtos.SourceCodeInfo.Location value)
A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.
|
DescriptorProtos.SourceCodeInfo.Builder |
addLocation(int index,
DescriptorProtos.SourceCodeInfo.Location.Builder builderForValue)
A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.
|
DescriptorProtos.SourceCodeInfo.Builder |
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.
|
DescriptorProtos.SourceCodeInfo.Location.Builder |
addLocationBuilder()
A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.
|
DescriptorProtos.SourceCodeInfo.Location.Builder |
addLocationBuilder(int index)
A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.
|
DescriptorProtos.SourceCodeInfo.Builder |
addRepeatedField(Descriptors.FieldDescriptor field,
Object value)
Like
setRepeatedField, but appends the value as a new element. |
DescriptorProtos.SourceCodeInfo |
build()
Constructs the message based on the state of the Builder.
|
DescriptorProtos.SourceCodeInfo |
buildPartial()
Like
MessageLite.Builder.build(), but does not throw an exception if the message
is missing required fields. |
DescriptorProtos.SourceCodeInfo.Builder |
clear()
Called by the initialization and clear code paths to allow subclasses to
reset any of their builtin fields back to the initial values.
|
DescriptorProtos.SourceCodeInfo.Builder |
clearField(Descriptors.FieldDescriptor field)
Clears the field.
|
DescriptorProtos.SourceCodeInfo.Builder |
clearLocation()
A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.
|
DescriptorProtos.SourceCodeInfo.Builder |
clearOneof(Descriptors.OneofDescriptor oneof)
TODO(jieluo): Clear it when all subclasses have implemented this method.
|
DescriptorProtos.SourceCodeInfo.Builder |
clone()
Clones the Builder.
|
DescriptorProtos.SourceCodeInfo |
getDefaultInstanceForType()
Get an instance of the type with no fields set.
|
static Descriptors.Descriptor |
getDescriptor() |
Descriptors.Descriptor |
getDescriptorForType()
Get the message's type's descriptor.
|
DescriptorProtos.SourceCodeInfo.Location |
getLocation(int index)
A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.
|
DescriptorProtos.SourceCodeInfo.Location.Builder |
getLocationBuilder(int index)
A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.
|
List<DescriptorProtos.SourceCodeInfo.Location.Builder> |
getLocationBuilderList()
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.
|
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.
|
List<? extends DescriptorProtos.SourceCodeInfo.LocationOrBuilder> |
getLocationOrBuilderList()
A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.
|
protected GeneratedMessageV3.FieldAccessorTable |
internalGetFieldAccessorTable()
Get the FieldAccessorTable for this type.
|
boolean |
isInitialized()
Returns true if all required fields in the message and all embedded
messages are set, false otherwise.
|
DescriptorProtos.SourceCodeInfo.Builder |
mergeFrom(CodedInputStream input,
ExtensionRegistryLite extensionRegistry)
Like
MessageLite.Builder.mergeFrom(CodedInputStream), but also
parses extensions. |
DescriptorProtos.SourceCodeInfo.Builder |
mergeFrom(DescriptorProtos.SourceCodeInfo other) |
DescriptorProtos.SourceCodeInfo.Builder |
mergeFrom(Message other)
Merge
other into the message being built. |
DescriptorProtos.SourceCodeInfo.Builder |
mergeUnknownFields(UnknownFieldSet unknownFields)
Merge some unknown fields into the
UnknownFieldSet for this
message. |
DescriptorProtos.SourceCodeInfo.Builder |
removeLocation(int index)
A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.
|
DescriptorProtos.SourceCodeInfo.Builder |
setField(Descriptors.FieldDescriptor field,
Object value)
Sets a field to the given value.
|
DescriptorProtos.SourceCodeInfo.Builder |
setLocation(int index,
DescriptorProtos.SourceCodeInfo.Location.Builder builderForValue)
A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.
|
DescriptorProtos.SourceCodeInfo.Builder |
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.
|
DescriptorProtos.SourceCodeInfo.Builder |
setRepeatedField(Descriptors.FieldDescriptor field,
int index,
Object value)
Sets an element of a repeated field to the given value.
|
DescriptorProtos.SourceCodeInfo.Builder |
setUnknownFields(UnknownFieldSet unknownFields)
Set the
UnknownFieldSet for this message. |
getAllFields, getField, getFieldBuilder, getOneofFieldDescriptor, getParentForChildren, getRepeatedField, getRepeatedFieldBuilder, getRepeatedFieldCount, getUnknownFields, hasField, hasOneof, internalGetMapField, internalGetMutableMapField, isClean, markClean, newBuilderForField, onBuilt, onChanged, setUnknownFieldsProto3findInitializationErrors, getInitializationErrorString, internalMergeFrom, mergeDelimitedFrom, mergeDelimitedFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, newUninitializedMessageException, toStringaddAll, addAll, mergeFrom, newUninitializedMessageExceptionequals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, waitfindInitializationErrors, getAllFields, getField, getInitializationErrorString, getOneofFieldDescriptor, getRepeatedField, getRepeatedFieldCount, getUnknownFields, hasField, hasOneofmergeFrompublic static final Descriptors.Descriptor getDescriptor()
protected GeneratedMessageV3.FieldAccessorTable internalGetFieldAccessorTable()
GeneratedMessageV3.BuilderinternalGetFieldAccessorTable in class GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public DescriptorProtos.SourceCodeInfo.Builder clear()
GeneratedMessageV3.Builderclear in interface Message.Builderclear in interface MessageLite.Builderclear in class GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public Descriptors.Descriptor getDescriptorForType()
Message.BuilderMessageOrBuilder.getDescriptorForType().getDescriptorForType in interface Message.BuildergetDescriptorForType in interface MessageOrBuildergetDescriptorForType in class GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public DescriptorProtos.SourceCodeInfo getDefaultInstanceForType()
MessageLiteOrBuildergetDefaultInstance() 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.getDefaultInstanceForType in interface MessageLiteOrBuildergetDefaultInstanceForType in interface MessageOrBuilderpublic DescriptorProtos.SourceCodeInfo build()
MessageLite.Builderbuild in interface Message.Builderbuild in interface MessageLite.Builderpublic DescriptorProtos.SourceCodeInfo buildPartial()
MessageLite.BuilderMessageLite.Builder.build(), but does not throw an exception if the message
is missing required fields. Instead, a partial message is returned.
Subsequent changes to the Builder will not affect the returned message.buildPartial in interface Message.BuilderbuildPartial in interface MessageLite.Builderpublic DescriptorProtos.SourceCodeInfo.Builder clone()
MessageLite.Builderclone in interface Message.Builderclone in interface MessageLite.Builderclone in class GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>Object.clone()public DescriptorProtos.SourceCodeInfo.Builder setField(Descriptors.FieldDescriptor field, Object value)
Message.BuilderMessageOrBuilder.getField(Descriptors.FieldDescriptor) would return.setField in interface Message.BuildersetField in class GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public DescriptorProtos.SourceCodeInfo.Builder clearField(Descriptors.FieldDescriptor field)
Message.BuilderclearField in interface Message.BuilderclearField in class GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public DescriptorProtos.SourceCodeInfo.Builder clearOneof(Descriptors.OneofDescriptor oneof)
AbstractMessage.BuilderclearOneof in interface Message.BuilderclearOneof in class GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public DescriptorProtos.SourceCodeInfo.Builder setRepeatedField(Descriptors.FieldDescriptor field, int index, Object value)
Message.BuilderMessageOrBuilder.getRepeatedField(Descriptors.FieldDescriptor,int) would
return.setRepeatedField in interface Message.BuildersetRepeatedField in class GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public DescriptorProtos.SourceCodeInfo.Builder addRepeatedField(Descriptors.FieldDescriptor field, Object value)
Message.BuildersetRepeatedField, but appends the value as a new element.addRepeatedField in interface Message.BuilderaddRepeatedField in class GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public DescriptorProtos.SourceCodeInfo.Builder mergeFrom(Message other)
Message.Builderother into the message being built. other must
have the exact same type as this (i.e.
getDescriptorForType() == other.getDescriptorForType()).
Merging occurs as follows. For each field:other,
then other's value overwrites the value in this message.other,
it is merged into the corresponding sub-message of this message
using the same merging rules.other are concatenated
with the elements in this message.Message::MergeFrom method in C++.mergeFrom in interface Message.BuildermergeFrom in class AbstractMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>public DescriptorProtos.SourceCodeInfo.Builder mergeFrom(DescriptorProtos.SourceCodeInfo other)
public final boolean isInitialized()
MessageLiteOrBuilderisInitialized in interface MessageLiteOrBuilderisInitialized in class GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public DescriptorProtos.SourceCodeInfo.Builder mergeFrom(CodedInputStream input, ExtensionRegistryLite extensionRegistry) throws IOException
MessageLite.BuilderMessageLite.Builder.mergeFrom(CodedInputStream), but also
parses extensions. The extensions that you want to be able to parse
must be registered in extensionRegistry. Extensions not in
the registry will be treated as unknown fields.mergeFrom in interface Message.BuildermergeFrom in interface MessageLite.BuildermergeFrom in class AbstractMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>IOExceptionpublic 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.SourceCodeInfoOrBuilderpublic 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.SourceCodeInfoOrBuilderpublic 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.SourceCodeInfoOrBuilderpublic DescriptorProtos.SourceCodeInfo.Builder 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 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 DescriptorProtos.SourceCodeInfo.Builder setLocation(int index, DescriptorProtos.SourceCodeInfo.Location.Builder builderForValue)
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 DescriptorProtos.SourceCodeInfo.Builder 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 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 DescriptorProtos.SourceCodeInfo.Builder 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 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 DescriptorProtos.SourceCodeInfo.Builder addLocation(DescriptorProtos.SourceCodeInfo.Location.Builder builderForValue)
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 DescriptorProtos.SourceCodeInfo.Builder addLocation(int index, DescriptorProtos.SourceCodeInfo.Location.Builder builderForValue)
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 DescriptorProtos.SourceCodeInfo.Builder addAllLocation(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 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 DescriptorProtos.SourceCodeInfo.Builder 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 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 DescriptorProtos.SourceCodeInfo.Builder 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 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 DescriptorProtos.SourceCodeInfo.Location.Builder getLocationBuilder(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 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;getLocationOrBuilder in interface DescriptorProtos.SourceCodeInfoOrBuilderpublic 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;getLocationOrBuilderList in interface DescriptorProtos.SourceCodeInfoOrBuilderpublic DescriptorProtos.SourceCodeInfo.Location.Builder addLocationBuilder()
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 DescriptorProtos.SourceCodeInfo.Location.Builder addLocationBuilder(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 List<DescriptorProtos.SourceCodeInfo.Location.Builder> getLocationBuilderList()
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 final DescriptorProtos.SourceCodeInfo.Builder setUnknownFields(UnknownFieldSet unknownFields)
Message.BuilderUnknownFieldSet for this message.setUnknownFields in interface Message.BuildersetUnknownFields in class GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public final DescriptorProtos.SourceCodeInfo.Builder mergeUnknownFields(UnknownFieldSet unknownFields)
Message.BuilderUnknownFieldSet for this
message.mergeUnknownFields in interface Message.BuildermergeUnknownFields in class GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>Copyright © 2008–2018. All rights reserved.