codegen: top-level message named `Option` shadows Rust prelude

[th0114nd]

Summary

When a proto file defines a top-level message Option, the generated pub struct Option shadows the Rust prelude Option<T>. Other generated code in the same package that uses Option<T> for oneof fields fails to compile:

error[E0107]: struct takes 0 generic arguments but 1 generic argument was supplied
  --> session.rs:517:26
    |
517 |     pub session_context: Option<__buffa::oneof::session_context::SessionContext>,
    |                          ^^^^^^ expected 0 generic arguments
    |
note: struct defined here, with 0 generic parameters
  --> message.rs:4427:12
    |
4427 | pub struct Option {
    |            ^^^^^^

Relation to #32 and #39

This is distinct from #32 (ancillary type name collisions, fixed by __buffa:: namespacing in #62) and #39 (qualifying Option in nested scopes). The __buffa:: fix in #62 handles collisions between generated ancillary names and user proto names. This bug is about a user proto name (message Option) shadowing a Rust prelude name, which affects the generated field type annotations for sibling messages in the same package.

Possible fix

The generated field types could use ::core::option::Option<T> instead of bare Option<T> unconditionally (or when a prelude-shadowing name is detected in the file set).

Reproduction

// option.proto
syntax = "proto3";
package example;

message Option {
  string label = 1;
}

message Container {
  oneof choice {
    string a = 1;
    int32 b = 2;
  }
}

// build.rs
fn main() {
    buffa_build::Config::new()
        .files(&["option.proto"])
        .includes(&["."])
        .out_dir("src/generated")
        .include_file("mod.rs")
        .compile()
        .unwrap();
}

The Container struct's oneof field will reference Option<...> which resolves to the generated Option struct instead of core::option::Option.

[iainmcgin]

[claude code] This is fixed on main as of #39 (merged f5690d71, 2026-04-23). Verified your exact reproduction — the generated Container.choice field is ::core::option::Option<__buffa::oneof::container::Choice> (fully qualified). The fix is the ImportResolver::for_file() detection from #39, which scans top-level message/enum names for prelude collisions and routes Option<...> emission through resolver.option().

If you're still seeing the failure, you may be on a build from before #39 landed, or have stale generated output — try a cargo clean and rebuild. Will be in v0.4.0.

Added your exact repro to prelude_shadow.proto as a regression cell in #66.

[th0114nd]

Correction: cross-file shadowing, not same-file

The original report above is slightly inaccurate — the single-file case (message Option + oneof in the same .proto file) was already handled by ImportResolver::for_file (from #39). The actual bug is cross-file shadowing within the same package:

1. File A (message.proto) defines message Option
2. File B (session.proto) has a oneof field (which generates Option<OneofEnum>)
3. ImportResolver::for_file only checks names within a single file, so file B's resolver doesn't see file A's Option
4. The stitcher combines both files into one module scope via include!, so file A's pub struct Option shadows the prelude in file B's code

The reproduction in the original report works if the message Option and message Container are in separate .proto files in the same package. In a single file, for_file already detects and qualifies Option.

Fix: #67 — unconditionally emit ::core::option::Option everywhere, eliminating the entire class of prelude-shadowing bugs regardless of file boundaries.

[th0114nd]

^ that's from the bot, this is me:

Hi Iain,

Thanks for taking a look. The original issue filed was a bit premature and didn't accurately capture the issue when it is in different files in the same package. I opted to simplify it by always qualifying the name, rather than extending check_names_for_prelude_collisions. The main downside of always qualifying AFAICT is just that the generated code is longer

[th0114nd]

But also if you are eager to get 0.4.0 this is not urgent by any means -- there's only a single package we have where this is an issue and it is not one commonly depended upon

[th0114nd]

Minimal reproduction

Two .proto files in the same package:

// message.proto
syntax = "proto3";
package pkg;

message Option {
  string text = 1;
}

// session.proto
syntax = "proto3";
package pkg;

message Wrapper {
  oneof kind {
    string a = 1;
  }
}

session.proto doesn't define message Option, so its per-file ImportResolver doesn't block Option. The generated session.rs emits:

pub struct Wrapper {
    pub kind: Option<__buffa::oneof::wrapper::Kind>,  // ← bare Option
    // ...
}

The stitcher combines both files into one module via include!, so message.proto's pub struct Option (0 generic params) shadows core::option::Option (1 generic param), producing:

error[E0107]: struct takes 0 generic arguments but 1 generic argument was supplied

The original report's single-file reproduction (both message Option and oneof in the same file) was already handled by #39. The bug only manifests when they're in separate files within the same package.

[th0114nd]

fixed by #67