Cannot put .capnp file in a submodule

[erickt]

(oops, accidentally submitted early)

Here's an example:

test.rs:

extern crate capnp;

pub mod submod {
    #[path = "../test_capnp.rs"]
    pub mod test_capnp;
}

fn main() { }

test.capnp:

@0xb05abd72309922f1;

struct Test {
  test @0 :Int64;

  method @1 :Method;
  enum Method {
    unkown @0;
  }
}

This errors with:

test_capnp.rs:36:40: 36:50 error: failed to resolve. Maybe a missing `extern crate test_capnp`?
test_capnp.rs:36     pub fn get_method(&self) -> Option<::test_capnp::test::method::Reader> {
                                                        ^~~~~~~~~~
test_capnp.rs:36:40: 36:74 error: use of undeclared type name `test_capnp::test::method::Reader`
test_capnp.rs:36     pub fn get_method(&self) -> Option<::test_capnp::test::method::Reader> {
                                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test_capnp.rs:64:40: 64:50 error: failed to resolve. Maybe a missing `extern crate test_capnp`?
test_capnp.rs:64     pub fn get_method(&self) -> Option<::test_capnp::test::method::Reader> {
                                                        ^~~~~~~~~~
test_capnp.rs:64:40: 64:74 error: use of undeclared type name `test_capnp::test::method::Reader`
test_capnp.rs:64     pub fn get_method(&self) -> Option<::test_capnp::test::method::Reader> {
                                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test_capnp.rs:68:38: 68:48 error: failed to resolve. Maybe a missing `extern crate test_capnp`?
test_capnp.rs:68     pub fn set_method(&self, value : ::test_capnp::test::method::Reader) {
                                                      ^~~~~~~~~~
test_capnp.rs:68:38: 68:72 error: use of undeclared type name `test_capnp::test::method::Reader`
test_capnp.rs:68     pub fn set_method(&self, value : ::test_capnp::test::method::Reader) {
                                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to 6 previous errors

The problem is that test_capnp.rs is using :: to try to get to the top of the file, but instead that is referring to the top of the crate. Unfortunately I don't think there's any shorthand to get to the top of the local file scope, so to do this, we would need to create a series of super::...s to walk up the current module chain to get to the root.

[dwrensha]

Yep, the generated code assumes that you add it as a module at the top level of the crate.

A shortcut to get the local file's scope wouldn't solve the general case, where we might have multiple schemas that refer to each other.

To support non-top-level generated modules, I think we need to add an annotation to tell capnpc-rust the module path that the generated code will be included as, where "::" is the default. This would be similar to how the C++ plugin lets you specify a namespace.

PS. Whoa, I didn't know about the #[path = ...] attribute. That seems useful, though it's too bad I can't make the path depend on a compile-time environment variable, e.g. #[path= concat!(env!("OUT_DIR"), "/test_capnp.rs")], which would be perfect for Cargo integration.

[futile]

Also running into this issue, currently hotfixing it by replacing all ::<top_level_name> with super.

[dwrensha]

This is mainly a code generation issue, so I'm closing in favor of this issue in capnpc-rust: capnproto/capnpc-rust#5

[dwrensha]

Reopening here, as capnpc-rust has been moved back into this repo.

[mashedcode]

As mentioned in #107, a possible but breaking change that would solve this issue might look like this broken link.

Discussion on this is a little bit scattered so I'll quote @dwrensha's links to related issues again:
capnproto/capnpc-rust#5
capnproto/capnpc-rust#30

I don't use the annotation stuff from capnproto/capnpc-rust#30 so I don't know how exactly it's related and fits or would even solve this issue. Some more explanation would be great.

I think we need to add an annotation to tell capnpc-rust the module path that the generated code will be included as, where "::" is the default. This would be similar to how the C++ plugin lets you specify a namespace.

@dwrensha So, the idea is to specify a namespace on top of each schema file to invoke non-default behavior?

Other than that I don't see anyone mentioning an approach to solve this issue.

More discussion on this that gets us somewhere would be appreciated!

Update: I'm not interested in this anymore.

[gibsond]

I am having a problem with this now. In trying to see what the solution is, my search led me to capnproto/capnpc-rust#5 first, than this one, and from here capnproto/capnpc-rust#30.

It seems that #5 was closed because #16 was open, and #16 was closed because of #5. Glad it has been re-opened as of August 30, 2018.

I can get mine to complie if I change the generated code with instances of, for example, ::foo_capnp::first_msg::second_msg to self::second_msg.

This is using edition = "2018" in the toml file.

I hope we can find a fix for this situation of using capnp List.

Thanks.

[olanod]

I'm also doing the replace hack ::{file}_capnp::{msg}::{sub_msg} -> self::{sub_msg}. What would take to use self, super, crate and favor relative paths instead of absolute ones?

[dwrensha]

Fixed in 57ab346.

[dwrensha]

To use the new feature, you need to import rust.capnp. Probably the easiest way to do that is to copy it and include it among your own schema files.

To indicate that you will include the generated code under the module foo::bar::baz, you would
add a file-level annotation $Rust.parentModule("foo::bar::baz").

[gibsond]

Thank-you!