# 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
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


@dataclass(eq=False, repr=False)
class Version(betterproto.Message):
    """The version number of protocol compiler."""

    major: int = betterproto.int32_field(1)
    minor: int = betterproto.int32_field(2)
    patch: int = betterproto.int32_field(3)
    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."""

    file_to_generate: List[str] = betterproto.string_field(1)
    """
    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)
    """The generator parameter passed on the command-line."""

    proto_file: List[
        "betterproto_lib_google_protobuf.FileDescriptorProto"
    ] = betterproto.message_field(15)
    """
    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: str = betterproto.string_field(1)
    """
    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)


@dataclass(eq=False, repr=False)
class CodeGeneratorResponseFile(betterproto.Message):
    """Represents a single generated file."""

    name: str = betterproto.string_field(1)
    """
    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)
    """
    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)
    """The file contents."""

    generated_code_info: "betterproto_lib_google_protobuf.GeneratedCodeInfo" = (
        betterproto.message_field(16)
    )
    """
    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.
    """