c++.capnp compiles to unusable module name about capnproto-rust

[dwrensha]

Does #412 help?

[quartox]

I made an external crate called capnp-crate mimicking this code and then added crate_provides("capnp_crate", [0xabcdef01234]) to my main crate's build.rs.

When I try to compile I still get errors in the generated code referencing capnp_crate::c++_capnp and it complains about the + in the name.

[dwrensha]

I'm assuming the c++.capnp schema file is this one from the main capnproto repo: https://github.com/capnproto/capnproto/blob/v2/c%2B%2B/src/capnp/c%2B%2B.capnp

Is there a reason that you need to generate Rust code for it at all?

Note that the capnproto-rust addressbook example refers to c++.capnp but does not generate Rust code for it, and this works without a problem.

[quartox]

There is also an Enum added to that file to create a new type of annotation. The compiler fails on the enum specifically. The annotation created from that enum is used widely in the other schemas that I need to use directly.

[dwrensha]

Ah, and unfortunately Rust raw identifiers don't support the '+' character either.

Some options:

1. We could allow the Rust.name annotation to change the name of files:

   capnproto-rust/capnpc/rust.capnp

   Line 9 in b85e041

   annotation name @0xc2fe4c6d100166d0 (field, struct, enum, enumerant, union, group) :Text;

   Then you could add a $Rust.name("cpp"); annotation in your c++.capnp file and the name would be avoided. This is nice in that it would use an existing mechanism, but maybe not nice in that it requires c++.capnp to import rust.capnp.
2. We could come up with an escaping scheme, so that the "+" deterministically gets mapped to something else in Rust code.
3. We could add an option to capnpc::CompilerCommand so that you could rename files in your build.rs.
4. You could rename c++.capnp to cpp.capnp in your project.

[quartox]

I am talking to the team that owns the schema files to see if we can change the name. If we are the only ones running into this and the change doesn't cause big problems (which is a risk) then option 4 seems like the simplest solution.