public static final class DescriptorProtos.SourceCodeInfo.Builder extends com.google.protobuf.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(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.
|
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,
java.lang.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)
|
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.
|
java.util.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.
|
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.
|
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(com.google.protobuf.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,
java.lang.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,
java.lang.Object value)
Sets an element of a repeated field to the given value.
|
DescriptorProtos.SourceCodeInfo.Builder |
setUnknownFields(com.google.protobuf.UnknownFieldSet unknownFields)
Set the
UnknownFieldSet for this message. |
getAllFields, getField, getFieldBuilder, getOneofFieldDescriptor, getRepeatedField, getRepeatedFieldBuilder, getRepeatedFieldCount, getUnknownFields, hasField, hasOneof, newBuilderForFieldfindInitializationErrors, getInitializationErrorString, mergeDelimitedFrom, mergeDelimitedFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, toStringmergeFromequals, getClass, hashCode, notify, notifyAll, wait, wait, waitfindInitializationErrors, getAllFields, getField, getInitializationErrorString, getOneofFieldDescriptor, getRepeatedField, getRepeatedFieldCount, getUnknownFields, hasField, hasOneofmergeFrompublic static final Descriptors.Descriptor getDescriptor()
public DescriptorProtos.SourceCodeInfo.Builder clear()
com.google.protobuf.GeneratedMessageV3.Builderclear in interface Message.Builderclear in interface MessageLite.Builderclear in class com.google.protobuf.GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public Descriptors.Descriptor getDescriptorForType()
Message.BuilderMessageOrBuilder.getDescriptorForType().getDescriptorForType in interface Message.BuildergetDescriptorForType in interface MessageOrBuildergetDescriptorForType in class com.google.protobuf.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 com.google.protobuf.GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>Object.clone()public DescriptorProtos.SourceCodeInfo.Builder setField(Descriptors.FieldDescriptor field, java.lang.Object value)
Message.BuilderMessageOrBuilder.getField(Descriptors.FieldDescriptor) would return.setField in interface Message.BuildersetField in class com.google.protobuf.GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public DescriptorProtos.SourceCodeInfo.Builder clearField(Descriptors.FieldDescriptor field)
Message.BuilderclearField in interface Message.BuilderclearField in class com.google.protobuf.GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public DescriptorProtos.SourceCodeInfo.Builder clearOneof(Descriptors.OneofDescriptor oneof)
AbstractMessage.BuilderclearOneof in interface Message.BuilderclearOneof in class com.google.protobuf.GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public DescriptorProtos.SourceCodeInfo.Builder setRepeatedField(Descriptors.FieldDescriptor field, int index, java.lang.Object value)
Message.BuilderMessageOrBuilder.getRepeatedField(Descriptors.FieldDescriptor,int) would return.setRepeatedField in interface Message.BuildersetRepeatedField in class com.google.protobuf.GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public DescriptorProtos.SourceCodeInfo.Builder addRepeatedField(Descriptors.FieldDescriptor field, java.lang.Object value)
Message.BuildersetRepeatedField, but appends the value as a new element.addRepeatedField in interface Message.BuilderaddRepeatedField in class com.google.protobuf.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:
* For singular primitive fields, if the field is set in other, then other's
value overwrites the value in this message.
* For singular message fields, if the field is set in other, it is merged into the
corresponding sub-message of this message using the same merging rules.
* For repeated fields, the elements in other are concatenated with the elements in
this message.
* For oneof groups, if the other message has one of the fields set, the group of this message
is cleared and replaced by the field of the other message, so that the oneof constraint is
preserved.
This is equivalent to the 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 com.google.protobuf.GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public DescriptorProtos.SourceCodeInfo.Builder mergeFrom(CodedInputStream input, ExtensionRegistryLite extensionRegistry) throws java.io.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>java.io.IOExceptionpublic 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;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 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 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 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;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 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;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 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;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 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;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 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;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 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;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 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;public DescriptorProtos.SourceCodeInfo.Builder 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;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 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;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 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;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 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;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;getLocationOrBuilder in interface DescriptorProtos.SourceCodeInfoOrBuilderpublic 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;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 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;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 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;public java.util.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 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;public final DescriptorProtos.SourceCodeInfo.Builder setUnknownFields(com.google.protobuf.UnknownFieldSet unknownFields)
Message.BuilderUnknownFieldSet for this message.setUnknownFields in interface Message.BuildersetUnknownFields in class com.google.protobuf.GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>public final DescriptorProtos.SourceCodeInfo.Builder mergeUnknownFields(com.google.protobuf.UnknownFieldSet unknownFields)
Message.BuilderUnknownFieldSet for this message.mergeUnknownFields in interface Message.BuildermergeUnknownFields in class com.google.protobuf.GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>