Package com.google.protobuf
Class DescriptorProtos.SourceCodeInfo.Builder
java.lang.Object
com.google.protobuf.AbstractMessageLite.Builder
com.google.protobuf.AbstractMessage.Builder<BuilderT>
com.google.protobuf.GeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
com.google.protobuf.DescriptorProtos.SourceCodeInfo.Builder
- All Implemented Interfaces:
DescriptorProtos.SourceCodeInfoOrBuilder,Message.Builder,MessageLite.Builder,MessageLiteOrBuilder,MessageOrBuilder,Cloneable
- Enclosing class:
- DescriptorProtos.SourceCodeInfo
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-
Nested Class Summary
Nested classes/interfaces inherited from class com.google.protobuf.AbstractMessageLite.Builder
AbstractMessageLite.Builder.LimitedInputStream -
Field Summary
FieldsModifier and TypeFieldDescriptionprivate intprivate RepeatedFieldBuilderV3<DescriptorProtos.SourceCodeInfo.Location,DescriptorProtos.SourceCodeInfo.Location.Builder, DescriptorProtos.SourceCodeInfo.LocationOrBuilder> -
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionaddAllLocation(Iterable<? extends DescriptorProtos.SourceCodeInfo.Location> values) A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.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.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.A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.addLocation(DescriptorProtos.SourceCodeInfo.Location.Builder builderForValue) A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.addLocationBuilder(int index) A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.addRepeatedField(Descriptors.FieldDescriptor field, Object value) LikesetRepeatedField, but appends the value as a new element.build()Constructs the message based on the state of the Builder.LikeMessageLite.Builder.build(), but does not throw an exception if the message is missing required fields.private voidprivate voidclear()Called by the initialization and clear code paths to allow subclasses to reset any of their builtin fields back to the initial values.Clears the field.A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.TODO: Clear it when all subclasses have implemented this method.clone()Clones the Builder.private voidGet an instance of the type with no fields set.static final Descriptors.DescriptorGet the message's type's descriptor.getLocation(int index) A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.getLocationBuilder(int index) A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.intA Location identifies a piece of source code in a .proto file which corresponds to a particular definition.private RepeatedFieldBuilderV3<DescriptorProtos.SourceCodeInfo.Location,DescriptorProtos.SourceCodeInfo.Location.Builder, DescriptorProtos.SourceCodeInfo.LocationOrBuilder> A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.getLocationOrBuilder(int index) A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.protected GeneratedMessageV3.FieldAccessorTableGet the FieldAccessorTable for this type.final booleanReturns true if all required fields in the message and all embedded messages are set, false otherwise.mergeFrom(CodedInputStream input, ExtensionRegistryLite extensionRegistry) LikeMessageLite.Builder.mergeFrom(CodedInputStream), but also parses extensions.Mergeotherinto the message being built.mergeUnknownFields(UnknownFieldSet unknownFields) Merge some unknown fields into theUnknownFieldSetfor this message.removeLocation(int index) A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.setField(Descriptors.FieldDescriptor field, Object value) Sets a field to the given value.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.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.setRepeatedField(Descriptors.FieldDescriptor field, int index, Object value) Sets an element of a repeated field to the given value.setUnknownFields(UnknownFieldSet unknownFields) Set theUnknownFieldSetfor this message.Methods inherited from class com.google.protobuf.GeneratedMessageV3.Builder
dispose, getAllFields, getField, getFieldBuilder, getOneofFieldDescriptor, getParentForChildren, getRepeatedField, getRepeatedFieldBuilder, getRepeatedFieldCount, getUnknownFields, getUnknownFieldSetBuilder, hasField, hasOneof, internalGetMapField, internalGetMapFieldReflection, internalGetMutableMapField, internalGetMutableMapFieldReflection, isClean, markClean, mergeUnknownLengthDelimitedField, mergeUnknownVarintField, newBuilderForField, onBuilt, onChanged, parseUnknownField, setUnknownFieldSetBuilder, setUnknownFieldsProto3Methods inherited from class com.google.protobuf.AbstractMessage.Builder
findInitializationErrors, getInitializationErrorString, internalMergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, newUninitializedMessageException, toStringMethods inherited from class com.google.protobuf.AbstractMessageLite.Builder
addAll, addAll, mergeDelimitedFrom, mergeDelimitedFrom, mergeFrom, newUninitializedMessageExceptionMethods inherited from class java.lang.Object
equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, waitMethods inherited from interface com.google.protobuf.Message.Builder
mergeDelimitedFrom, mergeDelimitedFromMethods inherited from interface com.google.protobuf.MessageLite.Builder
mergeFromMethods inherited from interface com.google.protobuf.MessageOrBuilder
findInitializationErrors, getAllFields, getField, getInitializationErrorString, getOneofFieldDescriptor, getRepeatedField, getRepeatedFieldCount, getUnknownFields, hasField, hasOneof
-
Field Details
-
bitField0_
private int bitField0_ -
location_
-
locationBuilder_
-
-
Constructor Details
-
Builder
private Builder() -
Builder
-
-
Method Details
-
getDescriptor
-
internalGetFieldAccessorTable
Description copied from class:GeneratedMessageV3.BuilderGet the FieldAccessorTable for this type. We can't have the message class pass this in to the constructor because of bootstrapping trouble with DescriptorProtos.- Specified by:
internalGetFieldAccessorTablein classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
clear
Description copied from class:GeneratedMessageV3.BuilderCalled by the initialization and clear code paths to allow subclasses to reset any of their builtin fields back to the initial values.- Specified by:
clearin interfaceMessage.Builder- Specified by:
clearin interfaceMessageLite.Builder- Overrides:
clearin classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
getDescriptorForType
Description copied from interface:Message.BuilderGet the message's type's descriptor. SeeMessageOrBuilder.getDescriptorForType().- Specified by:
getDescriptorForTypein interfaceMessage.Builder- Specified by:
getDescriptorForTypein interfaceMessageOrBuilder- Overrides:
getDescriptorForTypein classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
getDefaultInstanceForType
Description copied from interface:MessageLiteOrBuilderGet an instance of the type with no fields set. Because no fields are set, all getters for singular fields will return default values and repeated fields will appear empty. This may or may not be a singleton. This differs from thegetDefaultInstance()method of generated message classes in that this method is an abstract method of theMessageLiteinterface whereasgetDefaultInstance()is a static method of a specific class. They return the same thing.- Specified by:
getDefaultInstanceForTypein interfaceMessageLiteOrBuilder- Specified by:
getDefaultInstanceForTypein interfaceMessageOrBuilder
-
build
Description copied from interface:MessageLite.BuilderConstructs the message based on the state of the Builder. Subsequent changes to the Builder will not affect the returned message.- Specified by:
buildin interfaceMessage.Builder- Specified by:
buildin interfaceMessageLite.Builder
-
buildPartial
Description copied from interface:MessageLite.BuilderLikeMessageLite.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.- Specified by:
buildPartialin interfaceMessage.Builder- Specified by:
buildPartialin interfaceMessageLite.Builder
-
buildPartialRepeatedFields
-
buildPartial0
-
clone
Description copied from interface:MessageLite.BuilderClones the Builder.- Specified by:
clonein interfaceMessage.Builder- Specified by:
clonein interfaceMessageLite.Builder- Overrides:
clonein classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>- See Also:
-
setField
public DescriptorProtos.SourceCodeInfo.Builder setField(Descriptors.FieldDescriptor field, Object value) Description copied from interface:Message.BuilderSets a field to the given value. The value must be of the correct type for this field, that is, the same type thatMessageOrBuilder.getField(Descriptors.FieldDescriptor)returns.- Specified by:
setFieldin interfaceMessage.Builder- Overrides:
setFieldin classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
clearField
Description copied from interface:Message.BuilderClears the field. This is exactly equivalent to calling the generated "clear" accessor method corresponding to the field.- Specified by:
clearFieldin interfaceMessage.Builder- Overrides:
clearFieldin classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
clearOneof
Description copied from class:AbstractMessage.BuilderTODO: Clear it when all subclasses have implemented this method.- Specified by:
clearOneofin interfaceMessage.Builder- Overrides:
clearOneofin classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
setRepeatedField
public DescriptorProtos.SourceCodeInfo.Builder setRepeatedField(Descriptors.FieldDescriptor field, int index, Object value) Description copied from interface:Message.BuilderSets an element of a repeated field to the given value. The value must be of the correct type for this field; that is, the same type thatMessageOrBuilder.getRepeatedField(Descriptors.FieldDescriptor,int)returns.- Specified by:
setRepeatedFieldin interfaceMessage.Builder- Overrides:
setRepeatedFieldin classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
addRepeatedField
public DescriptorProtos.SourceCodeInfo.Builder addRepeatedField(Descriptors.FieldDescriptor field, Object value) Description copied from interface:Message.BuilderLikesetRepeatedField, but appends the value as a new element.- Specified by:
addRepeatedFieldin interfaceMessage.Builder- Overrides:
addRepeatedFieldin classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
mergeFrom
Description copied from interface:Message.BuilderMergeotherinto the message being built.othermust have the exact same type asthis(i.e.getDescriptorForType() == other.getDescriptorForType()).Merging occurs as follows. For each field:
* For singular primitive fields, if the field is set inother, thenother's value overwrites the value in this message.
* For singular message fields, if the field is set inother, it is merged into the corresponding sub-message of this message using the same merging rules.
* For repeated fields, the elements inotherare 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::MergeFrommethod in C++.- Specified by:
mergeFromin interfaceMessage.Builder- Overrides:
mergeFromin classAbstractMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
mergeFrom
-
isInitialized
public final boolean isInitialized()Description copied from interface:MessageLiteOrBuilderReturns true if all required fields in the message and all embedded messages are set, false otherwise.- Specified by:
isInitializedin interfaceMessageLiteOrBuilder- Overrides:
isInitializedin classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
mergeFrom
public DescriptorProtos.SourceCodeInfo.Builder mergeFrom(CodedInputStream input, ExtensionRegistryLite extensionRegistry) throws IOException Description copied from interface:MessageLite.BuilderLikeMessageLite.Builder.mergeFrom(CodedInputStream), but also parses extensions. The extensions that you want to be able to parse must be registered inextensionRegistry. Extensions not in the registry will be treated as unknown fields.- Specified by:
mergeFromin interfaceMessage.Builder- Specified by:
mergeFromin interfaceMessageLite.Builder- Overrides:
mergeFromin classAbstractMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>- Throws:
InvalidProtocolBufferException- the bytes read are not syntactically correct according to the protobuf wire format specification. The data is corrupt, incomplete, or was never a protobuf in the first place.IOException- an I/O error reading from the stream
-
ensureLocationIsMutable
private void ensureLocationIsMutable() -
getLocationList
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition. This information is intended to be useful to IDEs, code indexers, documentation generators, and similar tools. For example, say we have a file like: message Foo { optional string foo = 1; } Let's look at just the field definition: optional string foo = 1; ^ ^^ ^^ ^ ^^^ a bc de f ghi We have the following locations: span path represents [a,i) [ 4, 0, 2, 0 ] The whole field definition. [a,b) [ 4, 0, 2, 0, 4 ] The label (optional). [c,d) [ 4, 0, 2, 0, 5 ] The type (string). [e,f) [ 4, 0, 2, 0, 1 ] The name (foo). [g,h) [ 4, 0, 2, 0, 3 ] The number (1). Notes: - A location may refer to a repeated field itself (i.e. not to any particular index within it). This is used whenever a set of elements are logically enclosed in a single code segment. For example, an entire extend block (possibly containing multiple extension definitions) will have an outer location whose path refers to the "extensions" repeated field without an index. - Multiple locations may have the same path. This happens when a single logical declaration is spread out across multiple places. The most obvious example is the "extend" block again -- there may be multiple extend blocks in the same scope, each of which will have the same path. - A location's span is not always a subset of its parent's span. For example, the "extendee" of an extension declaration appears at the beginning of the "extend" block and is shared by all extensions within the block. - Just because a location's span is a subset of some other location's span does not mean that it is a descendant. For example, a "group" defines both a type and a field in a single declaration. Thus, the locations corresponding to the type and field and their components will overlap. - Code which tries to interpret locations should probably be designed to ignore those that it doesn't understand, as more types of locations could be recorded in the future.repeated .google.protobuf.SourceCodeInfo.Location location = 1;- Specified by:
getLocationListin interfaceDescriptorProtos.SourceCodeInfoOrBuilder
-
getLocationCount
public int getLocationCount()A Location identifies a piece of source code in a .proto file which corresponds to a particular definition. This information is intended to be useful to IDEs, code indexers, documentation generators, and similar tools. For example, say we have a file like: message Foo { optional string foo = 1; } Let's look at just the field definition: optional string foo = 1; ^ ^^ ^^ ^ ^^^ a bc de f ghi We have the following locations: span path represents [a,i) [ 4, 0, 2, 0 ] The whole field definition. [a,b) [ 4, 0, 2, 0, 4 ] The label (optional). [c,d) [ 4, 0, 2, 0, 5 ] The type (string). [e,f) [ 4, 0, 2, 0, 1 ] The name (foo). [g,h) [ 4, 0, 2, 0, 3 ] The number (1). Notes: - A location may refer to a repeated field itself (i.e. not to any particular index within it). This is used whenever a set of elements are logically enclosed in a single code segment. For example, an entire extend block (possibly containing multiple extension definitions) will have an outer location whose path refers to the "extensions" repeated field without an index. - Multiple locations may have the same path. This happens when a single logical declaration is spread out across multiple places. The most obvious example is the "extend" block again -- there may be multiple extend blocks in the same scope, each of which will have the same path. - A location's span is not always a subset of its parent's span. For example, the "extendee" of an extension declaration appears at the beginning of the "extend" block and is shared by all extensions within the block. - Just because a location's span is a subset of some other location's span does not mean that it is a descendant. For example, a "group" defines both a type and a field in a single declaration. Thus, the locations corresponding to the type and field and their components will overlap. - Code which tries to interpret locations should probably be designed to ignore those that it doesn't understand, as more types of locations could be recorded in the future.repeated .google.protobuf.SourceCodeInfo.Location location = 1;- Specified by:
getLocationCountin interfaceDescriptorProtos.SourceCodeInfoOrBuilder
-
getLocation
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition. This information is intended to be useful to IDEs, code indexers, documentation generators, and similar tools. For example, say we have a file like: message Foo { optional string foo = 1; } Let's look at just the field definition: optional string foo = 1; ^ ^^ ^^ ^ ^^^ a bc de f ghi We have the following locations: span path represents [a,i) [ 4, 0, 2, 0 ] The whole field definition. [a,b) [ 4, 0, 2, 0, 4 ] The label (optional). [c,d) [ 4, 0, 2, 0, 5 ] The type (string). [e,f) [ 4, 0, 2, 0, 1 ] The name (foo). [g,h) [ 4, 0, 2, 0, 3 ] The number (1). Notes: - A location may refer to a repeated field itself (i.e. not to any particular index within it). This is used whenever a set of elements are logically enclosed in a single code segment. For example, an entire extend block (possibly containing multiple extension definitions) will have an outer location whose path refers to the "extensions" repeated field without an index. - Multiple locations may have the same path. This happens when a single logical declaration is spread out across multiple places. The most obvious example is the "extend" block again -- there may be multiple extend blocks in the same scope, each of which will have the same path. - A location's span is not always a subset of its parent's span. For example, the "extendee" of an extension declaration appears at the beginning of the "extend" block and is shared by all extensions within the block. - Just because a location's span is a subset of some other location's span does not mean that it is a descendant. For example, a "group" defines both a type and a field in a single declaration. Thus, the locations corresponding to the type and field and their components will overlap. - Code which tries to interpret locations should probably be designed to ignore those that it doesn't understand, as more types of locations could be recorded in the future.repeated .google.protobuf.SourceCodeInfo.Location location = 1;- Specified by:
getLocationin interfaceDescriptorProtos.SourceCodeInfoOrBuilder
-
setLocation
public 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; -
setLocation
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; -
addLocation
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; -
addLocation
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; -
addLocation
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; -
addLocation
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; -
addAllLocation
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 descendant. For example, a "group" defines both a type and a field in a single declaration. Thus, the locations corresponding to the type and field and their components will overlap. - Code which tries to interpret locations should probably be designed to ignore those that it doesn't understand, as more types of locations could be recorded in the future.repeated .google.protobuf.SourceCodeInfo.Location location = 1; -
clearLocation
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition. This information is intended to be useful to IDEs, code indexers, documentation generators, and similar tools. For example, say we have a file like: message Foo { optional string foo = 1; } Let's look at just the field definition: optional string foo = 1; ^ ^^ ^^ ^ ^^^ a bc de f ghi We have the following locations: span path represents [a,i) [ 4, 0, 2, 0 ] The whole field definition. [a,b) [ 4, 0, 2, 0, 4 ] The label (optional). [c,d) [ 4, 0, 2, 0, 5 ] The type (string). [e,f) [ 4, 0, 2, 0, 1 ] The name (foo). [g,h) [ 4, 0, 2, 0, 3 ] The number (1). Notes: - A location may refer to a repeated field itself (i.e. not to any particular index within it). This is used whenever a set of elements are logically enclosed in a single code segment. For example, an entire extend block (possibly containing multiple extension definitions) will have an outer location whose path refers to the "extensions" repeated field without an index. - Multiple locations may have the same path. This happens when a single logical declaration is spread out across multiple places. The most obvious example is the "extend" block again -- there may be multiple extend blocks in the same scope, each of which will have the same path. - A location's span is not always a subset of its parent's span. For example, the "extendee" of an extension declaration appears at the beginning of the "extend" block and is shared by all extensions within the block. - Just because a location's span is a subset of some other location's span does not mean that it is a descendant. For example, a "group" defines both a type and a field in a single declaration. Thus, the locations corresponding to the type and field and their components will overlap. - Code which tries to interpret locations should probably be designed to ignore those that it doesn't understand, as more types of locations could be recorded in the future.repeated .google.protobuf.SourceCodeInfo.Location location = 1; -
removeLocation
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; -
getLocationBuilder
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
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition. This information is intended to be useful to IDEs, code indexers, documentation generators, and similar tools. For example, say we have a file like: message Foo { optional string foo = 1; } Let's look at just the field definition: optional string foo = 1; ^ ^^ ^^ ^ ^^^ a bc de f ghi We have the following locations: span path represents [a,i) [ 4, 0, 2, 0 ] The whole field definition. [a,b) [ 4, 0, 2, 0, 4 ] The label (optional). [c,d) [ 4, 0, 2, 0, 5 ] The type (string). [e,f) [ 4, 0, 2, 0, 1 ] The name (foo). [g,h) [ 4, 0, 2, 0, 3 ] The number (1). Notes: - A location may refer to a repeated field itself (i.e. not to any particular index within it). This is used whenever a set of elements are logically enclosed in a single code segment. For example, an entire extend block (possibly containing multiple extension definitions) will have an outer location whose path refers to the "extensions" repeated field without an index. - Multiple locations may have the same path. This happens when a single logical declaration is spread out across multiple places. The most obvious example is the "extend" block again -- there may be multiple extend blocks in the same scope, each of which will have the same path. - A location's span is not always a subset of its parent's span. For example, the "extendee" of an extension declaration appears at the beginning of the "extend" block and is shared by all extensions within the block. - Just because a location's span is a subset of some other location's span does not mean that it is a descendant. For example, a "group" defines both a type and a field in a single declaration. Thus, the locations corresponding to the type and field and their components will overlap. - Code which tries to interpret locations should probably be designed to ignore those that it doesn't understand, as more types of locations could be recorded in the future.repeated .google.protobuf.SourceCodeInfo.Location location = 1;- Specified by:
getLocationOrBuilderin interfaceDescriptorProtos.SourceCodeInfoOrBuilder
-
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;- Specified by:
getLocationOrBuilderListin interfaceDescriptorProtos.SourceCodeInfoOrBuilder
-
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; -
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; -
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; -
getLocationFieldBuilder
-
setUnknownFields
public final DescriptorProtos.SourceCodeInfo.Builder setUnknownFields(UnknownFieldSet unknownFields) Description copied from interface:Message.BuilderSet theUnknownFieldSetfor this message.- Specified by:
setUnknownFieldsin interfaceMessage.Builder- Overrides:
setUnknownFieldsin classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
mergeUnknownFields
public final DescriptorProtos.SourceCodeInfo.Builder mergeUnknownFields(UnknownFieldSet unknownFields) Description copied from interface:Message.BuilderMerge some unknown fields into theUnknownFieldSetfor this message.- Specified by:
mergeUnknownFieldsin interfaceMessage.Builder- Overrides:
mergeUnknownFieldsin classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-