Class PluginProtos.CodeGeneratorRequest.Builder (3.19.4)

publicstaticfinalclass PluginProtos.CodeGeneratorRequest.BuilderextendsGeneratedMessageV3.Builder<PluginProtos.CodeGeneratorRequest.Builder>implementsPluginProtos.CodeGeneratorRequestOrBuilder

An encoded CodeGeneratorRequest is written to the plugin's stdin.

Protobuf type google.protobuf.compiler.CodeGeneratorRequest

Inheritance

Object > AbstractMessageLite.Builder<MessageType,BuilderType> > AbstractMessage.Builder<BuilderType> > GeneratedMessageV3.Builder > PluginProtos.CodeGeneratorRequest.Builder

Implements

PluginProtos.CodeGeneratorRequestOrBuilder

Inherited Members

publicstaticfinalDescriptors.DescriptorgetDescriptor()

publicPluginProtos.CodeGeneratorRequest.BuilderaddAllFileToGenerate(Iterable<String>values)

The .proto files that were explicitly listed on the command-line. The code generator should generate code only for these files. Each file's descriptor will be included in proto_file, below.

repeated string file_to_generate = 1;

publicPluginProtos.CodeGeneratorRequest.BuilderaddAllProtoFile(Iterable<?extendsDescriptorProtos.FileDescriptorProto>values)

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicPluginProtos.CodeGeneratorRequest.BuilderaddFileToGenerate(Stringvalue)

The .proto files that were explicitly listed on the command-line. The code generator should generate code only for these files. Each file's descriptor will be included in proto_file, below.

repeated string file_to_generate = 1;

publicPluginProtos.CodeGeneratorRequest.BuilderaddFileToGenerateBytes(ByteStringvalue)

The .proto files that were explicitly listed on the command-line. The code generator should generate code only for these files. Each file's descriptor will be included in proto_file, below.

repeated string file_to_generate = 1;

publicPluginProtos.CodeGeneratorRequest.BuilderaddProtoFile(DescriptorProtos.FileDescriptorProtovalue)

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicPluginProtos.CodeGeneratorRequest.BuilderaddProtoFile(DescriptorProtos.FileDescriptorProto.BuilderbuilderForValue)

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicPluginProtos.CodeGeneratorRequest.BuilderaddProtoFile(intindex,DescriptorProtos.FileDescriptorProtovalue)

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicPluginProtos.CodeGeneratorRequest.BuilderaddProtoFile(intindex,DescriptorProtos.FileDescriptorProto.BuilderbuilderForValue)

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicDescriptorProtos.FileDescriptorProto.BuilderaddProtoFileBuilder()

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicDescriptorProtos.FileDescriptorProto.BuilderaddProtoFileBuilder(intindex)

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicPluginProtos.CodeGeneratorRequest.BuilderaddRepeatedField(Descriptors.FieldDescriptorfield,Objectvalue)

GeneratedMessageV3.Builder<BuilderType>.addRepeatedField(Descriptors.FieldDescriptor field, Object value)

publicPluginProtos.CodeGeneratorRequestbuild()

publicPluginProtos.CodeGeneratorRequestbuildPartial()

publicPluginProtos.CodeGeneratorRequest.Builderclear()

Called by the initialization and clear code paths to allow subclasses to reset any of their builtin fields back to the initial values.

GeneratedMessageV3.Builder<BuilderType>.clear()

publicPluginProtos.CodeGeneratorRequest.BuilderclearCompilerVersion()

The version number of protocol compiler.

optional .google.protobuf.compiler.Version compiler_version = 3;

publicPluginProtos.CodeGeneratorRequest.BuilderclearField(Descriptors.FieldDescriptorfield)

GeneratedMessageV3.Builder<BuilderType>.clearField(Descriptors.FieldDescriptor field)

publicPluginProtos.CodeGeneratorRequest.BuilderclearFileToGenerate()

The .proto files that were explicitly listed on the command-line. The code generator should generate code only for these files. Each file's descriptor will be included in proto_file, below.

repeated string file_to_generate = 1;

publicPluginProtos.CodeGeneratorRequest.BuilderclearOneof(Descriptors.OneofDescriptoroneof)

TODO(jieluo): Clear it when all subclasses have implemented this method.

GeneratedMessageV3.Builder<BuilderType>.clearOneof(Descriptors.OneofDescriptor oneof)

publicPluginProtos.CodeGeneratorRequest.BuilderclearParameter()

The generator parameter passed on the command-line.

optional string parameter = 2;

publicPluginProtos.CodeGeneratorRequest.BuilderclearProtoFile()

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicPluginProtos.CodeGeneratorRequest.Builderclone()

Clones the Builder.

GeneratedMessageV3.Builder<BuilderType>.clone()

publicPluginProtos.VersiongetCompilerVersion()

The version number of protocol compiler.

optional .google.protobuf.compiler.Version compiler_version = 3;

publicPluginProtos.Version.BuildergetCompilerVersionBuilder()

The version number of protocol compiler.

optional .google.protobuf.compiler.Version compiler_version = 3;

publicPluginProtos.VersionOrBuildergetCompilerVersionOrBuilder()

The version number of protocol compiler.

optional .google.protobuf.compiler.Version compiler_version = 3;

publicPluginProtos.CodeGeneratorRequestgetDefaultInstanceForType()

Get an instance of the type with no fields set. Because no fields are set, all getters for singular fields will return default values and repeated fields will appear empty. This may or may not be a singleton. This differs from the getDefaultInstance() method of generated message classes in that this method is an abstract method of the MessageLite interface whereas getDefaultInstance() is a static method of a specific class. They return the same thing.

publicDescriptors.DescriptorgetDescriptorForType()

Get the message's type's descriptor. This differs from the getDescriptor() method of generated message classes in that this method is an abstract method of the Message interface whereas getDescriptor() is a static method of a specific class. They return the same thing.

GeneratedMessageV3.Builder<BuilderType>.getDescriptorForType()

publicStringgetFileToGenerate(intindex)

The .proto files that were explicitly listed on the command-line. The code generator should generate code only for these files. Each file's descriptor will be included in proto_file, below.

repeated string file_to_generate = 1;

publicByteStringgetFileToGenerateBytes(intindex)

The .proto files that were explicitly listed on the command-line. The code generator should generate code only for these files. Each file's descriptor will be included in proto_file, below.

repeated string file_to_generate = 1;

publicintgetFileToGenerateCount()

The .proto files that were explicitly listed on the command-line. The code generator should generate code only for these files. Each file's descriptor will be included in proto_file, below.

repeated string file_to_generate = 1;

publicProtocolStringListgetFileToGenerateList()

The .proto files that were explicitly listed on the command-line. The code generator should generate code only for these files. Each file's descriptor will be included in proto_file, below.

repeated string file_to_generate = 1;

publicStringgetParameter()

The generator parameter passed on the command-line.

optional string parameter = 2;

publicByteStringgetParameterBytes()

The generator parameter passed on the command-line.

optional string parameter = 2;

publicDescriptorProtos.FileDescriptorProtogetProtoFile(intindex)

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicDescriptorProtos.FileDescriptorProto.BuildergetProtoFileBuilder(intindex)

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicList<DescriptorProtos.FileDescriptorProto.Builder>getProtoFileBuilderList()

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicintgetProtoFileCount()

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicList<DescriptorProtos.FileDescriptorProto>getProtoFileList()

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicDescriptorProtos.FileDescriptorProtoOrBuildergetProtoFileOrBuilder(intindex)

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicList<?extendsDescriptorProtos.FileDescriptorProtoOrBuilder>getProtoFileOrBuilderList()

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicbooleanhasCompilerVersion()

The version number of protocol compiler.

optional .google.protobuf.compiler.Version compiler_version = 3;

publicbooleanhasParameter()

The generator parameter passed on the command-line.

optional string parameter = 2;

protectedGeneratedMessageV3.FieldAccessorTableinternalGetFieldAccessorTable()

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.

GeneratedMessageV3.Builder<BuilderType>.internalGetFieldAccessorTable()

publicfinalbooleanisInitialized()

Returns true if all required fields in the message and all embedded messages are set, false otherwise.

See also: MessageOrBuilder#getInitializationErrorString()

GeneratedMessageV3.Builder<BuilderType>.isInitialized()

publicPluginProtos.CodeGeneratorRequest.BuildermergeCompilerVersion(PluginProtos.Versionvalue)

The version number of protocol compiler.

optional .google.protobuf.compiler.Version compiler_version = 3;

publicPluginProtos.CodeGeneratorRequest.BuildermergeFrom(CodedInputStreaminput,ExtensionRegistryLiteextensionRegistry)

Like Builder#mergeFrom(CodedInputStream), but also parses extensions. The extensions that you want to be able to parse must be registered in extensionRegistry. Extensions not in the registry will be treated as unknown fields.

AbstractMessage.Builder<BuilderType>.mergeFrom(CodedInputStream input, ExtensionRegistryLite extensionRegistry)

publicPluginProtos.CodeGeneratorRequest.BuildermergeFrom(Messageother)

Merge other into the message being built. other must have the exact same type as this (i.e. getDescriptorForType() == other.getDescriptorForType()).

Merging occurs as follows. For each field:

• For singular primitive fields, if the field is set in other, then other's value overwrites the value in this message.
  
• For singular message fields, if the field is set in other, it is merged into the corresponding sub-message of this message using the same merging rules.
  
• For repeated fields, the elements in other are concatenated with the elements in this message.
  

• For oneof groups, if the other message has one of the fields set, the group of this message is cleared and replaced by the field of the other message, so that the oneof constraint is preserved.

  This is equivalent to the Message::MergeFrom method in C++.

AbstractMessage.Builder<BuilderType>.mergeFrom(Message other)

publicPluginProtos.CodeGeneratorRequest.BuildermergeFrom(PluginProtos.CodeGeneratorRequestother)

publicfinalPluginProtos.CodeGeneratorRequest.BuildermergeUnknownFields(UnknownFieldSetunknownFields)

Merge some unknown fields into the UnknownFieldSet for this message.

GeneratedMessageV3.Builder<BuilderType>.mergeUnknownFields(UnknownFieldSet unknownFields)

publicPluginProtos.CodeGeneratorRequest.BuilderremoveProtoFile(intindex)

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicPluginProtos.CodeGeneratorRequest.BuildersetCompilerVersion(PluginProtos.Versionvalue)

The version number of protocol compiler.

optional .google.protobuf.compiler.Version compiler_version = 3;

publicPluginProtos.CodeGeneratorRequest.BuildersetCompilerVersion(PluginProtos.Version.BuilderbuilderForValue)

The version number of protocol compiler.

optional .google.protobuf.compiler.Version compiler_version = 3;

publicPluginProtos.CodeGeneratorRequest.BuildersetField(Descriptors.FieldDescriptorfield,Objectvalue)

GeneratedMessageV3.Builder<BuilderType>.setField(Descriptors.FieldDescriptor field, Object value)

publicPluginProtos.CodeGeneratorRequest.BuildersetFileToGenerate(intindex,Stringvalue)

The .proto files that were explicitly listed on the command-line. The code generator should generate code only for these files. Each file's descriptor will be included in proto_file, below.

repeated string file_to_generate = 1;

publicPluginProtos.CodeGeneratorRequest.BuildersetParameter(Stringvalue)

The generator parameter passed on the command-line.

optional string parameter = 2;

publicPluginProtos.CodeGeneratorRequest.BuildersetParameterBytes(ByteStringvalue)

The generator parameter passed on the command-line.

optional string parameter = 2;

publicPluginProtos.CodeGeneratorRequest.BuildersetProtoFile(intindex,DescriptorProtos.FileDescriptorProtovalue)

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicPluginProtos.CodeGeneratorRequest.BuildersetProtoFile(intindex,DescriptorProtos.FileDescriptorProto.BuilderbuilderForValue)

FileDescriptorProtos for all files in files_to_generate and everything they import. The files will appear in topological order, so each file appears before any file that imports it. protoc guarantees that all proto_files will be written after the fields above, even though this is not technically guaranteed by the protobuf wire format. This theoretically could allow a plugin to stream in the FileDescriptorProtos and handle them one by one rather than read the entire set into memory at once. However, as of this writing, this is not similarly optimized on protoc's end -- it will store all fields in memory at once before sending them to the plugin. Type names of fields and extensions in the FileDescriptorProto are always fully qualified.

repeated .google.protobuf.FileDescriptorProto proto_file = 15;

publicPluginProtos.CodeGeneratorRequest.BuildersetRepeatedField(Descriptors.FieldDescriptorfield,intindex,Objectvalue)

GeneratedMessageV3.Builder<BuilderType>.setRepeatedField(Descriptors.FieldDescriptor field, int index, Object value)

publicfinalPluginProtos.CodeGeneratorRequest.BuildersetUnknownFields(UnknownFieldSetunknownFields)

GeneratedMessageV3.Builder<BuilderType>.setUnknownFields(UnknownFieldSet unknownFields)