Struct GeneratedFile 

pub struct GeneratedFile {
    pub name: String,
    pub package: String,
    pub kind: GeneratedFileKind,
    pub content: String,
}

One generated output file.

Each .proto produces up to five content files (<stem>.rs, <stem>.__view.rs, <stem>.__oneof.rs, <stem>.__view_oneof.rs, <stem>.__ext.rs) and each proto package produces one <dotted.pkg>.mod.rs stitcher that include!s the content files and authors the pub mod __buffa { … } ancillary tree. Ancillary kinds with no content for that input file (e.g. a message with no oneofs and no extensions) are omitted, and the stitcher’s include! set is filtered to match. The __buffa wrapper (and each view / oneof / ext submodule inside it) is itself omitted when it would be empty, so packages with only owned messages emit no __buffa block at all. See DESIGN.md → “Generated code layout”.

Consumers normally only need to wire up the GeneratedFileKind::PackageMod entries (one per package); the per-proto content kinds are reached transitively via include! from the stitcher. Write all files to disk; build a module tree from only the PackageMod ones.

With CodeGenConfig::file_per_package set, the per-proto content kinds are not emitted at all — the single <dotted.pkg>.rs (still kind PackageMod) inlines what the stitcher would include!.

Fields

name: String

The output file path (e.g., "my.pkg.foo.rs" or "my.pkg.mod.rs").

package: String

The proto package this file belongs to.

kind: GeneratedFileKind

What this file contains. Build integrations only need to wire up GeneratedFileKind::PackageMod files; everything else is reached via include! from there.

content: String

The generated Rust source code.

Trait Implementations

impl Debug for GeneratedFile

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.