Added support for @generated marker (#382)
This commit is contained in:
parent
496eba2750
commit
f31d51cf3c
File diff suppressed because it is too large
Load Diff
@ -1,14 +1,17 @@
|
||||
# Generated by the protocol buffer compiler. DO NOT EDIT!
|
||||
# sources: google/protobuf/compiler/plugin.proto
|
||||
# plugin: python-betterproto
|
||||
# This file has been @generated
|
||||
from dataclasses import dataclass
|
||||
from typing import List
|
||||
|
||||
import betterproto
|
||||
from betterproto.grpc.grpclib_server import ServiceBase
|
||||
import betterproto.lib.google.protobuf as betterproto_lib_google_protobuf
|
||||
|
||||
|
||||
class CodeGeneratorResponseFeature(betterproto.Enum):
|
||||
"""Sync with code_generator.h."""
|
||||
|
||||
FEATURE_NONE = 0
|
||||
FEATURE_PROTO3_OPTIONAL = 1
|
||||
|
||||
@ -20,54 +23,69 @@ class Version(betterproto.Message):
|
||||
major: int = betterproto.int32_field(1)
|
||||
minor: int = betterproto.int32_field(2)
|
||||
patch: int = betterproto.int32_field(3)
|
||||
# A suffix for alpha, beta or rc release, e.g., "alpha-1", "rc2". It should
|
||||
# be empty for mainline stable releases.
|
||||
suffix: str = betterproto.string_field(4)
|
||||
"""
|
||||
A suffix for alpha, beta or rc release, e.g., "alpha-1", "rc2". It should
|
||||
be empty for mainline stable releases.
|
||||
"""
|
||||
|
||||
|
||||
@dataclass(eq=False, repr=False)
|
||||
class CodeGeneratorRequest(betterproto.Message):
|
||||
"""An encoded CodeGeneratorRequest is written to the plugin's stdin."""
|
||||
|
||||
# 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.
|
||||
file_to_generate: List[str] = betterproto.string_field(1)
|
||||
# The generator parameter passed on the command-line.
|
||||
"""
|
||||
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.
|
||||
"""
|
||||
|
||||
parameter: str = betterproto.string_field(2)
|
||||
# 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.
|
||||
"""The generator parameter passed on the command-line."""
|
||||
|
||||
proto_file: List[
|
||||
"betterproto_lib_google_protobuf.FileDescriptorProto"
|
||||
] = betterproto.message_field(15)
|
||||
# The version number of protocol compiler.
|
||||
"""
|
||||
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.
|
||||
"""
|
||||
|
||||
compiler_version: "Version" = betterproto.message_field(3)
|
||||
"""The version number of protocol compiler."""
|
||||
|
||||
|
||||
@dataclass(eq=False, repr=False)
|
||||
class CodeGeneratorResponse(betterproto.Message):
|
||||
"""The plugin writes an encoded CodeGeneratorResponse to stdout."""
|
||||
|
||||
# Error message. If non-empty, code generation failed. The plugin process
|
||||
# should exit with status code zero even if it reports an error in this way.
|
||||
# This should be used to indicate errors in .proto files which prevent the
|
||||
# code generator from generating correct code. Errors which indicate a
|
||||
# problem in protoc itself -- such as the input CodeGeneratorRequest being
|
||||
# unparseable -- should be reported by writing a message to stderr and
|
||||
# exiting with a non-zero status code.
|
||||
error: str = betterproto.string_field(1)
|
||||
# A bitmask of supported features that the code generator supports. This is a
|
||||
# bitwise "or" of values from the Feature enum.
|
||||
"""
|
||||
Error message. If non-empty, code generation failed. The plugin process
|
||||
should exit with status code zero even if it reports an error in this way.
|
||||
This should be used to indicate errors in .proto files which prevent the
|
||||
code generator from generating correct code. Errors which indicate a
|
||||
problem in protoc itself -- such as the input CodeGeneratorRequest being
|
||||
unparseable -- should be reported by writing a message to stderr and
|
||||
exiting with a non-zero status code.
|
||||
"""
|
||||
|
||||
supported_features: int = betterproto.uint64_field(2)
|
||||
"""
|
||||
A bitmask of supported features that the code generator supports. This is a
|
||||
bitwise "or" of values from the Feature enum.
|
||||
"""
|
||||
|
||||
file: List["CodeGeneratorResponseFile"] = betterproto.message_field(15)
|
||||
|
||||
|
||||
@ -75,54 +93,60 @@ class CodeGeneratorResponse(betterproto.Message):
|
||||
class CodeGeneratorResponseFile(betterproto.Message):
|
||||
"""Represents a single generated file."""
|
||||
|
||||
# The file name, relative to the output directory. The name must not contain
|
||||
# "." or ".." components and must be relative, not be absolute (so, the file
|
||||
# cannot lie outside the output directory). "/" must be used as the path
|
||||
# separator, not "\". If the name is omitted, the content will be appended to
|
||||
# the previous file. This allows the generator to break large files into
|
||||
# small chunks, and allows the generated text to be streamed back to protoc
|
||||
# so that large files need not reside completely in memory at one time. Note
|
||||
# that as of this writing protoc does not optimize for this -- it will read
|
||||
# the entire CodeGeneratorResponse before writing files to disk.
|
||||
name: str = betterproto.string_field(1)
|
||||
# If non-empty, indicates that the named file should already exist, and the
|
||||
# content here is to be inserted into that file at a defined insertion point.
|
||||
# This feature allows a code generator to extend the output produced by
|
||||
# another code generator. The original generator may provide insertion
|
||||
# points by placing special annotations in the file that look like:
|
||||
# @@protoc_insertion_point(NAME) The annotation can have arbitrary text
|
||||
# before and after it on the line, which allows it to be placed in a comment.
|
||||
# NAME should be replaced with an identifier naming the point -- this is what
|
||||
# other generators will use as the insertion_point. Code inserted at this
|
||||
# point will be placed immediately above the line containing the insertion
|
||||
# point (thus multiple insertions to the same point will come out in the
|
||||
# order they were added). The double-@ is intended to make it unlikely that
|
||||
# the generated code could contain things that look like insertion points by
|
||||
# accident. For example, the C++ code generator places the following line in
|
||||
# the .pb.h files that it generates: //
|
||||
# @@protoc_insertion_point(namespace_scope) This line appears within the
|
||||
# scope of the file's package namespace, but outside of any particular class.
|
||||
# Another plugin can then specify the insertion_point "namespace_scope" to
|
||||
# generate additional classes or other declarations that should be placed in
|
||||
# this scope. Note that if the line containing the insertion point begins
|
||||
# with whitespace, the same whitespace will be added to every line of the
|
||||
# inserted text. This is useful for languages like Python, where indentation
|
||||
# matters. In these languages, the insertion point comment should be
|
||||
# indented the same amount as any inserted code will need to be in order to
|
||||
# work correctly in that context. The code generator that generates the
|
||||
# initial file and the one which inserts into it must both run as part of a
|
||||
# single invocation of protoc. Code generators are executed in the order in
|
||||
# which they appear on the command line. If |insertion_point| is present,
|
||||
# |name| must also be present.
|
||||
"""
|
||||
The file name, relative to the output directory. The name must not contain
|
||||
"." or ".." components and must be relative, not be absolute (so, the file
|
||||
cannot lie outside the output directory). "/" must be used as the path
|
||||
separator, not "\". If the name is omitted, the content will be appended to
|
||||
the previous file. This allows the generator to break large files into
|
||||
small chunks, and allows the generated text to be streamed back to protoc
|
||||
so that large files need not reside completely in memory at one time. Note
|
||||
that as of this writing protoc does not optimize for this -- it will read
|
||||
the entire CodeGeneratorResponse before writing files to disk.
|
||||
"""
|
||||
|
||||
insertion_point: str = betterproto.string_field(2)
|
||||
# The file contents.
|
||||
"""
|
||||
If non-empty, indicates that the named file should already exist, and the
|
||||
content here is to be inserted into that file at a defined insertion point.
|
||||
This feature allows a code generator to extend the output produced by
|
||||
another code generator. The original generator may provide insertion
|
||||
points by placing special annotations in the file that look like:
|
||||
@@protoc_insertion_point(NAME) The annotation can have arbitrary text
|
||||
before and after it on the line, which allows it to be placed in a comment.
|
||||
NAME should be replaced with an identifier naming the point -- this is what
|
||||
other generators will use as the insertion_point. Code inserted at this
|
||||
point will be placed immediately above the line containing the insertion
|
||||
point (thus multiple insertions to the same point will come out in the
|
||||
order they were added). The double-@ is intended to make it unlikely that
|
||||
the generated code could contain things that look like insertion points by
|
||||
accident. For example, the C++ code generator places the following line in
|
||||
the .pb.h files that it generates: //
|
||||
@@protoc_insertion_point(namespace_scope) This line appears within the
|
||||
scope of the file's package namespace, but outside of any particular class.
|
||||
Another plugin can then specify the insertion_point "namespace_scope" to
|
||||
generate additional classes or other declarations that should be placed in
|
||||
this scope. Note that if the line containing the insertion point begins
|
||||
with whitespace, the same whitespace will be added to every line of the
|
||||
inserted text. This is useful for languages like Python, where indentation
|
||||
matters. In these languages, the insertion point comment should be
|
||||
indented the same amount as any inserted code will need to be in order to
|
||||
work correctly in that context. The code generator that generates the
|
||||
initial file and the one which inserts into it must both run as part of a
|
||||
single invocation of protoc. Code generators are executed in the order in
|
||||
which they appear on the command line. If |insertion_point| is present,
|
||||
|name| must also be present.
|
||||
"""
|
||||
|
||||
content: str = betterproto.string_field(15)
|
||||
# Information describing the file content being inserted. If an insertion
|
||||
# point is used, this information will be appropriately offset and inserted
|
||||
# into the code generation metadata for the generated files.
|
||||
"""The file contents."""
|
||||
|
||||
generated_code_info: "betterproto_lib_google_protobuf.GeneratedCodeInfo" = (
|
||||
betterproto.message_field(16)
|
||||
)
|
||||
|
||||
|
||||
import betterproto.lib.google.protobuf as betterproto_lib_google_protobuf
|
||||
"""
|
||||
Information describing the file content being inserted. If an insertion
|
||||
point is used, this information will be appropriately offset and inserted
|
||||
into the code generation metadata for the generated files.
|
||||
"""
|
||||
|
@ -1,6 +1,7 @@
|
||||
# Generated by the protocol buffer compiler. DO NOT EDIT!
|
||||
# sources: {{ ', '.join(output_file.input_filenames) }}
|
||||
# plugin: python-betterproto
|
||||
# This file has been @generated
|
||||
{% for i in output_file.python_module_imports|sort %}
|
||||
import {{ i }}
|
||||
{% endfor %}
|
||||
|
Loading…
x
Reference in New Issue
Block a user