Skip to content

fix: skip view generation on FooView name collision (#32)#37

Closed
th0114nd wants to merge 1 commit intoanthropics:mainfrom
th0114nd:fix/view-name-conflict
Closed

fix: skip view generation on FooView name collision (#32)#37
th0114nd wants to merge 1 commit intoanthropics:mainfrom
th0114nd:fix/view-name-conflict

Conversation

@th0114nd
Copy link
Copy Markdown
Contributor

@th0114nd th0114nd commented Apr 5, 2026

Summary

  • Replaces the hard ViewNameConflict error with graceful view skipping when a user-defined message FooView collides with the generated view type for sibling message Foo.
  • Collects proto FQNs of colliding messages into a skip set, then gates generate_view calls at both the top-level and nested message recursion points.
  • Removes the ViewNameConflict error variant from CodeGenError.

Fixes #32.

Stacked on #3 (fix/oneof-shadows-parent-name).

Test plan

  • test_view_name_collision_skips_view_generation — verifies both owned structs exist, FooViewView is generated, and Foo's MessageView impl is absent.
  • test_view_name_conflict_not_checked_when_views_disabled — unchanged, still passes.
  • Full workspace tests pass (cargo test --workspace).
  • cargo clippy --all-targets clean.

Made with Cursor

…ng (anthropics#32)

When a user-defined message `FooView` exists alongside `Foo`, the
generated `FooView<'a>` view type for `Foo` would collide. Previously
this was a hard `ViewNameConflict` error blocking the entire crate.

Now the codegen skips generating the view for `Foo` and continues.
The user-defined `FooView` message (and its own view `FooViewView`)
are generated normally. Downstream code that references `Foo`'s view
will get a targeted compile error rather than a blanket codegen failure.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Made-with: Cursor
@th0114nd th0114nd force-pushed the fix/view-name-conflict branch from d324e6f to 6061e0e Compare April 17, 2026 21:14
@th0114nd th0114nd marked this pull request as ready for review April 17, 2026 21:14
@th0114nd
Copy link
Copy Markdown
Contributor Author

ideally closed in favor of #54

@iainmcgin
Copy link
Copy Markdown
Collaborator

[claude code] This is superseded by #54, which fixes #32 structurally by moving all view types into a parallel view:: module tree — Foo and FooView then both get views (view::FooView and view::FooViewView) with no skip needed. See buffa-codegen/src/tests/naming.rs::test_top_level_view_no_longer_collides_with_named_view_message on that branch.

Recommend closing this in favor of #54; happy to discuss if you see a case the namespacing approach misses.

@th0114nd
Copy link
Copy Markdown
Contributor Author

Nope, aligned with #54 as the more comprehensive approach

@th0114nd th0114nd closed this Apr 23, 2026
@github-actions github-actions Bot locked and limited conversation to collaborators Apr 23, 2026
@iainmcgin
Copy link
Copy Markdown
Collaborator

[claude code] #62 has now merged, which fixes #32 structurally (views live under pkg::__buffa::view::, so Foo and FooView both get views). This PR can be closed — thanks again for surfacing the issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ViewNameConflict: codegen fails when message FooView exists alongside message Foo

2 participants