Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Distinguishing FooBar and fooBar when converting to snake case module name #545

Open
daniestevez opened this issue Feb 7, 2025 · 2 comments

Comments

@daniestevez
Copy link

I have a small patch for the module_name function in capnpc that inserts a leading _ in the module name when the camel case name begins by a lower case letter. This is intended to prevent name clashes between the module generated for something like a struct FooBar and the module generated from something like annotation fooBar (these cases occur in the capnp codebase I am using). Would this patch be something that could be contributed upstream, perhaps as an option rather than as default behaviour? I'm willing to do all the heavy lifting to submit a PR that is mergeable. I'm mostly asking for direction about what would be the preferred approach.

@dwrensha
Copy link
Member

dwrensha commented Feb 8, 2025

What if we updated the name annotation in rust.capnp so that it could be used to annotate annotations?

annotation name @0xc2fe4c6d100166d0 (field, struct, enum, enumerant, union, group) :Text;
# Rename something in the generated code. The value that you specify in this
# annotation should follow capnp capitalization conventions. So, for example,
# a struct should use CamelCase capitalization like `StructFoo`, even though
# that will get translated to a `struct_foo` module in the generated Rust code.
#
# TODO: support annotating more kinds of things with this.

Would that work for you?

@daniestevez
Copy link
Author

That might work but it does not seem a great solution for my use case, mainly because of two reasons:

  • The capnp code base is rather large and I would have to go through it manually adding these annotations where needed. We also have C++ and Python tools making use of these capnp files, and I would need to check that this introduces no conflicts. For simplicity, I would rather implement a solution that doesn't involve modifying the capnp files.

  • According to the comment in the code you linked, the name that is given is the capnp name, rather than the Rust name, so this does not seem to allow me to rename an annotation fooBar into _foo_bar. I guess I could rename the annotation fooBar into something like fooBarAnnotation, so that its Rust module ends up being foo_bar_annotation instead of foo_bar, which would clash with struct FooBar. However, the problem is that I also have Rust code generated in build.rs that needs to be able to predict the names of the Rust types and modules generated by capnpc based on the names in the capnp files. Allowing renames introduces an extra layer of complexity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants