Package com.google.protobuf
Class DescriptorProtos.SourceCodeInfo.Builder
- java.lang.Object
-
- com.google.protobuf.AbstractMessageLite.Builder
-
- com.google.protobuf.AbstractMessage.Builder<BuilderType>
-
- 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 typegoogle.protobuf.SourceCodeInfo
-
-
Method Summary
All Methods Static Methods Instance Methods Concrete Methods Modifier and Type Method Description DescriptorProtos.SourceCodeInfo.Builder
addAllLocation(Iterable<? extends DescriptorProtos.SourceCodeInfo.Location> values)
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.DescriptorProtos.SourceCodeInfo.Builder
addLocation(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
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(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(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.Location.Builder
addLocationBuilder()
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.DescriptorProtos.SourceCodeInfo.Location.Builder
addLocationBuilder(int index)
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.DescriptorProtos.SourceCodeInfo.Builder
addRepeatedField(Descriptors.FieldDescriptor field, Object value)
LikesetRepeatedField
, but appends the value as a new element.DescriptorProtos.SourceCodeInfo
build()
Constructs the message based on the state of the Builder.DescriptorProtos.SourceCodeInfo
buildPartial()
LikeMessageLite.Builder.build()
, but does not throw an exception if the message is missing required fields.DescriptorProtos.SourceCodeInfo.Builder
clear()
Called by the initialization and clear code paths to allow subclasses to reset any of their builtin fields back to the initial values.DescriptorProtos.SourceCodeInfo.Builder
clearField(Descriptors.FieldDescriptor field)
Clears the field.DescriptorProtos.SourceCodeInfo.Builder
clearLocation()
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.DescriptorProtos.SourceCodeInfo.Builder
clearOneof(Descriptors.OneofDescriptor oneof)
TODO(jieluo): Clear it when all subclasses have implemented this method.DescriptorProtos.SourceCodeInfo.Builder
clone()
Clones the Builder.DescriptorProtos.SourceCodeInfo
getDefaultInstanceForType()
Get an instance of the type with no fields set.static Descriptors.Descriptor
getDescriptor()
Descriptors.Descriptor
getDescriptorForType()
Get the message's type's descriptor.DescriptorProtos.SourceCodeInfo.Location
getLocation(int index)
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.DescriptorProtos.SourceCodeInfo.Location.Builder
getLocationBuilder(int index)
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.List<DescriptorProtos.SourceCodeInfo.Location.Builder>
getLocationBuilderList()
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.int
getLocationCount()
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.List<DescriptorProtos.SourceCodeInfo.Location>
getLocationList()
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.DescriptorProtos.SourceCodeInfo.LocationOrBuilder
getLocationOrBuilder(int index)
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.List<? extends DescriptorProtos.SourceCodeInfo.LocationOrBuilder>
getLocationOrBuilderList()
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.protected GeneratedMessageV3.FieldAccessorTable
internalGetFieldAccessorTable()
Get the FieldAccessorTable for this type.boolean
isInitialized()
Returns true if all required fields in the message and all embedded messages are set, false otherwise.DescriptorProtos.SourceCodeInfo.Builder
mergeFrom(CodedInputStream input, ExtensionRegistryLite extensionRegistry)
LikeMessageLite.Builder.mergeFrom(CodedInputStream)
, but also parses extensions.DescriptorProtos.SourceCodeInfo.Builder
mergeFrom(DescriptorProtos.SourceCodeInfo other)
DescriptorProtos.SourceCodeInfo.Builder
mergeFrom(Message other)
Mergeother
into the message being built.DescriptorProtos.SourceCodeInfo.Builder
mergeUnknownFields(UnknownFieldSet unknownFields)
Merge some unknown fields into theUnknownFieldSet
for this message.DescriptorProtos.SourceCodeInfo.Builder
removeLocation(int index)
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.DescriptorProtos.SourceCodeInfo.Builder
setField(Descriptors.FieldDescriptor field, Object value)
Sets a field to the given value.DescriptorProtos.SourceCodeInfo.Builder
setLocation(int index, DescriptorProtos.SourceCodeInfo.Location value)
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.Builder builderForValue)
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.DescriptorProtos.SourceCodeInfo.Builder
setRepeatedField(Descriptors.FieldDescriptor field, int index, Object value)
Sets an element of a repeated field to the given value.DescriptorProtos.SourceCodeInfo.Builder
setUnknownFields(UnknownFieldSet unknownFields)
Set theUnknownFieldSet
for this message.-
Methods inherited from class com.google.protobuf.GeneratedMessageV3.Builder
getAllFields, getField, getFieldBuilder, getOneofFieldDescriptor, getParentForChildren, getRepeatedField, getRepeatedFieldBuilder, getRepeatedFieldCount, getUnknownFields, getUnknownFieldSetBuilder, hasField, hasOneof, internalGetMapField, internalGetMutableMapField, isClean, markClean, mergeUnknownLengthDelimitedField, mergeUnknownVarintField, newBuilderForField, onBuilt, onChanged, parseUnknownField, setUnknownFieldSetBuilder, setUnknownFieldsProto3
-
Methods inherited from class com.google.protobuf.AbstractMessage.Builder
findInitializationErrors, getInitializationErrorString, internalMergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, newUninitializedMessageException, toString
-
Methods inherited from class com.google.protobuf.AbstractMessageLite.Builder
addAll, addAll, mergeDelimitedFrom, mergeDelimitedFrom, mergeFrom, newUninitializedMessageException
-
Methods inherited from class java.lang.Object
equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait
-
Methods inherited from interface com.google.protobuf.Message.Builder
mergeDelimitedFrom, mergeDelimitedFrom
-
Methods inherited from interface com.google.protobuf.MessageLite.Builder
mergeFrom
-
Methods inherited from interface com.google.protobuf.MessageOrBuilder
findInitializationErrors, getAllFields, getField, getInitializationErrorString, getOneofFieldDescriptor, getRepeatedField, getRepeatedFieldCount, getUnknownFields, hasField, hasOneof
-
-
-
-
Method Detail
-
getDescriptor
public static final Descriptors.Descriptor getDescriptor()
-
internalGetFieldAccessorTable
protected GeneratedMessageV3.FieldAccessorTable internalGetFieldAccessorTable()
Description copied from class:GeneratedMessageV3.Builder
Get the FieldAccessorTable for this type. We can't have the message class pass this in to the constructor because of bootstrapping trouble with DescriptorProtos.- Specified by:
internalGetFieldAccessorTable
in classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
clear
public DescriptorProtos.SourceCodeInfo.Builder clear()
Description copied from class:GeneratedMessageV3.Builder
Called by the initialization and clear code paths to allow subclasses to reset any of their builtin fields back to the initial values.- Specified by:
clear
in interfaceMessage.Builder
- Specified by:
clear
in interfaceMessageLite.Builder
- Overrides:
clear
in classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
getDescriptorForType
public Descriptors.Descriptor getDescriptorForType()
Description copied from interface:Message.Builder
Get the message's type's descriptor. SeeMessageOrBuilder.getDescriptorForType()
.- Specified by:
getDescriptorForType
in interfaceMessage.Builder
- Specified by:
getDescriptorForType
in interfaceMessageOrBuilder
- Overrides:
getDescriptorForType
in classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
getDefaultInstanceForType
public DescriptorProtos.SourceCodeInfo getDefaultInstanceForType()
Description copied from interface:MessageLiteOrBuilder
Get an instance of the type with no fields set. Because no fields are set, all getters for singular fields will return default values and repeated fields will appear empty. This may or may not be a singleton. This differs from thegetDefaultInstance()
method of generated message classes in that this method is an abstract method of theMessageLite
interface whereasgetDefaultInstance()
is a static method of a specific class. They return the same thing.- Specified by:
getDefaultInstanceForType
in interfaceMessageLiteOrBuilder
- Specified by:
getDefaultInstanceForType
in interfaceMessageOrBuilder
-
build
public DescriptorProtos.SourceCodeInfo build()
Description copied from interface:MessageLite.Builder
Constructs the message based on the state of the Builder. Subsequent changes to the Builder will not affect the returned message.- Specified by:
build
in interfaceMessage.Builder
- Specified by:
build
in interfaceMessageLite.Builder
-
buildPartial
public DescriptorProtos.SourceCodeInfo buildPartial()
Description copied from interface:MessageLite.Builder
LikeMessageLite.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:
buildPartial
in interfaceMessage.Builder
- Specified by:
buildPartial
in interfaceMessageLite.Builder
-
clone
public DescriptorProtos.SourceCodeInfo.Builder clone()
Description copied from interface:MessageLite.Builder
Clones the Builder.- Specified by:
clone
in interfaceMessage.Builder
- Specified by:
clone
in interfaceMessageLite.Builder
- Overrides:
clone
in classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
- See Also:
Object.clone()
-
setField
public DescriptorProtos.SourceCodeInfo.Builder setField(Descriptors.FieldDescriptor field, Object value)
Description copied from interface:Message.Builder
Sets 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:
setField
in interfaceMessage.Builder
- Overrides:
setField
in classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
clearField
public DescriptorProtos.SourceCodeInfo.Builder clearField(Descriptors.FieldDescriptor field)
Description copied from interface:Message.Builder
Clears the field. This is exactly equivalent to calling the generated "clear" accessor method corresponding to the field.- Specified by:
clearField
in interfaceMessage.Builder
- Overrides:
clearField
in classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
clearOneof
public DescriptorProtos.SourceCodeInfo.Builder clearOneof(Descriptors.OneofDescriptor oneof)
Description copied from class:AbstractMessage.Builder
TODO(jieluo): Clear it when all subclasses have implemented this method.- Specified by:
clearOneof
in interfaceMessage.Builder
- Overrides:
clearOneof
in classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
setRepeatedField
public DescriptorProtos.SourceCodeInfo.Builder setRepeatedField(Descriptors.FieldDescriptor field, int index, Object value)
Description copied from interface:Message.Builder
Sets 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:
setRepeatedField
in interfaceMessage.Builder
- Overrides:
setRepeatedField
in classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
addRepeatedField
public DescriptorProtos.SourceCodeInfo.Builder addRepeatedField(Descriptors.FieldDescriptor field, Object value)
Description copied from interface:Message.Builder
LikesetRepeatedField
, but appends the value as a new element.- Specified by:
addRepeatedField
in interfaceMessage.Builder
- Overrides:
addRepeatedField
in classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
mergeFrom
public DescriptorProtos.SourceCodeInfo.Builder mergeFrom(Message other)
Description copied from interface:Message.Builder
Mergeother
into the message being built.other
must 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 inother
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++.- Specified by:
mergeFrom
in interfaceMessage.Builder
- Overrides:
mergeFrom
in classAbstractMessage.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
mergeFrom
public DescriptorProtos.SourceCodeInfo.Builder mergeFrom(DescriptorProtos.SourceCodeInfo other)
-
isInitialized
public final boolean isInitialized()
Description copied from interface:MessageLiteOrBuilder
Returns true if all required fields in the message and all embedded messages are set, false otherwise.- Specified by:
isInitialized
in interfaceMessageLiteOrBuilder
- Overrides:
isInitialized
in classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
mergeFrom
public DescriptorProtos.SourceCodeInfo.Builder mergeFrom(CodedInputStream input, ExtensionRegistryLite extensionRegistry) throws IOException
Description copied from interface:MessageLite.Builder
LikeMessageLite.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:
mergeFrom
in interfaceMessage.Builder
- Specified by:
mergeFrom
in interfaceMessageLite.Builder
- Overrides:
mergeFrom
in 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
-
getLocationList
public List<DescriptorProtos.SourceCodeInfo.Location> getLocationList()
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition. This information is intended to be useful to IDEs, code indexers, documentation generators, and similar tools. For example, say we have a file like: message Foo { optional string foo = 1; } Let's look at just the field definition: optional string foo = 1; ^ ^^ ^^ ^ ^^^ a bc de f ghi We have the following locations: span path represents [a,i) [ 4, 0, 2, 0 ] The whole field definition. [a,b) [ 4, 0, 2, 0, 4 ] The label (optional). [c,d) [ 4, 0, 2, 0, 5 ] The type (string). [e,f) [ 4, 0, 2, 0, 1 ] The name (foo). [g,h) [ 4, 0, 2, 0, 3 ] The number (1). Notes: - A location may refer to a repeated field itself (i.e. not to any particular index within it). This is used whenever a set of elements are logically enclosed in a single code segment. For example, an entire extend block (possibly containing multiple extension definitions) will have an outer location whose path refers to the "extensions" repeated field without an index. - Multiple locations may have the same path. This happens when a single logical declaration is spread out across multiple places. The most obvious example is the "extend" block again -- there may be multiple extend blocks in the same scope, each of which will have the same path. - A location's span is not always a subset of its parent's span. For example, the "extendee" of an extension declaration appears at the beginning of the "extend" block and is shared by all extensions within the block. - Just because a location's span is a subset of some other location's span does not mean that it is a descendant. For example, a "group" defines both a type and a field in a single declaration. Thus, the locations corresponding to the type and field and their components will overlap. - Code which tries to interpret locations should probably be designed to ignore those that it doesn't understand, as more types of locations could be recorded in the future.
repeated .google.protobuf.SourceCodeInfo.Location location = 1;
- Specified by:
getLocationList
in 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:
getLocationCount
in interfaceDescriptorProtos.SourceCodeInfoOrBuilder
-
getLocation
public DescriptorProtos.SourceCodeInfo.Location getLocation(int index)
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition. This information is intended to be useful to IDEs, code indexers, documentation generators, and similar tools. For example, say we have a file like: message Foo { optional string foo = 1; } Let's look at just the field definition: optional string foo = 1; ^ ^^ ^^ ^ ^^^ a bc de f ghi We have the following locations: span path represents [a,i) [ 4, 0, 2, 0 ] The whole field definition. [a,b) [ 4, 0, 2, 0, 4 ] The label (optional). [c,d) [ 4, 0, 2, 0, 5 ] The type (string). [e,f) [ 4, 0, 2, 0, 1 ] The name (foo). [g,h) [ 4, 0, 2, 0, 3 ] The number (1). Notes: - A location may refer to a repeated field itself (i.e. not to any particular index within it). This is used whenever a set of elements are logically enclosed in a single code segment. For example, an entire extend block (possibly containing multiple extension definitions) will have an outer location whose path refers to the "extensions" repeated field without an index. - Multiple locations may have the same path. This happens when a single logical declaration is spread out across multiple places. The most obvious example is the "extend" block again -- there may be multiple extend blocks in the same scope, each of which will have the same path. - A location's span is not always a subset of its parent's span. For example, the "extendee" of an extension declaration appears at the beginning of the "extend" block and is shared by all extensions within the block. - Just because a location's span is a subset of some other location's span does not mean that it is a descendant. For example, a "group" defines both a type and a field in a single declaration. Thus, the locations corresponding to the type and field and their components will overlap. - Code which tries to interpret locations should probably be designed to ignore those that it doesn't understand, as more types of locations could be recorded in the future.
repeated .google.protobuf.SourceCodeInfo.Location location = 1;
- Specified by:
getLocation
in interfaceDescriptorProtos.SourceCodeInfoOrBuilder
-
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
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;
-
removeLocation
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;
-
getLocationBuilder
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;
-
getLocationOrBuilder
public DescriptorProtos.SourceCodeInfo.LocationOrBuilder getLocationOrBuilder(int index)
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition. This information is intended to be useful to IDEs, code indexers, documentation generators, and similar tools. For example, say we have a file like: message Foo { optional string foo = 1; } Let's look at just the field definition: optional string foo = 1; ^ ^^ ^^ ^ ^^^ a bc de f ghi We have the following locations: span path represents [a,i) [ 4, 0, 2, 0 ] The whole field definition. [a,b) [ 4, 0, 2, 0, 4 ] The label (optional). [c,d) [ 4, 0, 2, 0, 5 ] The type (string). [e,f) [ 4, 0, 2, 0, 1 ] The name (foo). [g,h) [ 4, 0, 2, 0, 3 ] The number (1). Notes: - A location may refer to a repeated field itself (i.e. not to any particular index within it). This is used whenever a set of elements are logically enclosed in a single code segment. For example, an entire extend block (possibly containing multiple extension definitions) will have an outer location whose path refers to the "extensions" repeated field without an index. - Multiple locations may have the same path. This happens when a single logical declaration is spread out across multiple places. The most obvious example is the "extend" block again -- there may be multiple extend blocks in the same scope, each of which will have the same path. - A location's span is not always a subset of its parent's span. For example, the "extendee" of an extension declaration appears at the beginning of the "extend" block and is shared by all extensions within the block. - Just because a location's span is a subset of some other location's span does not mean that it is a descendant. For example, a "group" defines both a type and a field in a single declaration. Thus, the locations corresponding to the type and field and their components will overlap. - Code which tries to interpret locations should probably be designed to ignore those that it doesn't understand, as more types of locations could be recorded in the future.
repeated .google.protobuf.SourceCodeInfo.Location location = 1;
- Specified by:
getLocationOrBuilder
in interfaceDescriptorProtos.SourceCodeInfoOrBuilder
-
getLocationOrBuilderList
public List<? extends DescriptorProtos.SourceCodeInfo.LocationOrBuilder> getLocationOrBuilderList()
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition. This information is intended to be useful to IDEs, code indexers, documentation generators, and similar tools. For example, say we have a file like: message Foo { optional string foo = 1; } Let's look at just the field definition: optional string foo = 1; ^ ^^ ^^ ^ ^^^ a bc de f ghi We have the following locations: span path represents [a,i) [ 4, 0, 2, 0 ] The whole field definition. [a,b) [ 4, 0, 2, 0, 4 ] The label (optional). [c,d) [ 4, 0, 2, 0, 5 ] The type (string). [e,f) [ 4, 0, 2, 0, 1 ] The name (foo). [g,h) [ 4, 0, 2, 0, 3 ] The number (1). Notes: - A location may refer to a repeated field itself (i.e. not to any particular index within it). This is used whenever a set of elements are logically enclosed in a single code segment. For example, an entire extend block (possibly containing multiple extension definitions) will have an outer location whose path refers to the "extensions" repeated field without an index. - Multiple locations may have the same path. This happens when a single logical declaration is spread out across multiple places. The most obvious example is the "extend" block again -- there may be multiple extend blocks in the same scope, each of which will have the same path. - A location's span is not always a subset of its parent's span. For example, the "extendee" of an extension declaration appears at the beginning of the "extend" block and is shared by all extensions within the block. - Just because a location's span is a subset of some other location's span does not mean that it is a descendant. For example, a "group" defines both a type and a field in a single declaration. Thus, the locations corresponding to the type and field and their components will overlap. - Code which tries to interpret locations should probably be designed to ignore those that it doesn't understand, as more types of locations could be recorded in the future.
repeated .google.protobuf.SourceCodeInfo.Location location = 1;
- Specified by:
getLocationOrBuilderList
in interfaceDescriptorProtos.SourceCodeInfoOrBuilder
-
addLocationBuilder
public 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;
-
addLocationBuilder
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;
-
getLocationBuilderList
public List<DescriptorProtos.SourceCodeInfo.Location.Builder> getLocationBuilderList()
A Location identifies a piece of source code in a .proto file which corresponds to a particular definition. This information is intended to be useful to IDEs, code indexers, documentation generators, and similar tools. For example, say we have a file like: message Foo { optional string foo = 1; } Let's look at just the field definition: optional string foo = 1; ^ ^^ ^^ ^ ^^^ a bc de f ghi We have the following locations: span path represents [a,i) [ 4, 0, 2, 0 ] The whole field definition. [a,b) [ 4, 0, 2, 0, 4 ] The label (optional). [c,d) [ 4, 0, 2, 0, 5 ] The type (string). [e,f) [ 4, 0, 2, 0, 1 ] The name (foo). [g,h) [ 4, 0, 2, 0, 3 ] The number (1). Notes: - A location may refer to a repeated field itself (i.e. not to any particular index within it). This is used whenever a set of elements are logically enclosed in a single code segment. For example, an entire extend block (possibly containing multiple extension definitions) will have an outer location whose path refers to the "extensions" repeated field without an index. - Multiple locations may have the same path. This happens when a single logical declaration is spread out across multiple places. The most obvious example is the "extend" block again -- there may be multiple extend blocks in the same scope, each of which will have the same path. - A location's span is not always a subset of its parent's span. For example, the "extendee" of an extension declaration appears at the beginning of the "extend" block and is shared by all extensions within the block. - Just because a location's span is a subset of some other location's span does not mean that it is a 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;
-
setUnknownFields
public final DescriptorProtos.SourceCodeInfo.Builder setUnknownFields(UnknownFieldSet unknownFields)
Description copied from interface:Message.Builder
Set theUnknownFieldSet
for this message.- Specified by:
setUnknownFields
in interfaceMessage.Builder
- Overrides:
setUnknownFields
in classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
mergeUnknownFields
public final DescriptorProtos.SourceCodeInfo.Builder mergeUnknownFields(UnknownFieldSet unknownFields)
Description copied from interface:Message.Builder
Merge some unknown fields into theUnknownFieldSet
for this message.- Specified by:
mergeUnknownFields
in interfaceMessage.Builder
- Overrides:
mergeUnknownFields
in classGeneratedMessageV3.Builder<DescriptorProtos.SourceCodeInfo.Builder>
-
-