Problem with nested message types and rust code generator 33.4

[Day Rush]

Hi -

I'm building an interface in rust to a large library of C & C# code that uses protocol buffers for it's IPC encoding. In the .proto files there are a lot of message structures like

message Foo {

    message Inner {

        message Context {

            double field1 = 1;

            ... }

        google.protobuf.Timestamp at = 1;

        Context cx1 = 2;

        Context cx2 = 3;

        ... }

    double value = 1;

    repeated Inner inner_list = 2;

    ... }

And the rust code generator doesn't appear to use consistent case folding in the generated code. Specifically, I see references to

    super::super::super::foo::inner::Context

producing error messages like

    error[E0433]: failed to resolve: could not find `foo` in `super`

which go away if I hand edit the generated code to use the capitalized Foo from the generated pub struct Foo. This seems like a bug, and I thought it would be good to check if there might be code generator option magic that I am missing.

As a side note, the proto code builds perfectly under the 3.7.2 stepancheg release, so maybe this is a bleeding edge problem?

Thanks in advance
- d

[Em Rauch]

Thank you for kicking the tires on the new RustProtobuf implementation! You can open an issue on github with a repro we can take a look.

> which go away if I hand edit the generated code to use the capitalized Foo from the generated pub struct Foo

The general case in Rust you can't nest structs in structs (unlike, say, in Java where you can put a class in a class). So the workaround for nested types here is that we emit the Foo struct for the Foo message itself, and then a `foo` mod for anything that is nested inside in the .proto file, so in your example there should be a structure that looks like this:

```

struct Foo {...}

mod foo {

   struct Inner { ... }

   mod inner {

       struct Context { ... }

   }

   }

}

```

The reason we do all of the super::super:: is so that you should be able to put your gencode might be in some mod in your crate that isn't top level (so handwritten code would probably write `crate::foo::inner::Context` but we can't because it should work for you to make your own `mod proto` or something that our gencode won't know about).

If you hand edited it to `super::super::super::Foo::inner::Context` and that worked then something really weird is going on; these kind of nested types are covered by tests and also widely used within Google and we haven't gotten reports of the issue, so I would have to guess some form of user-error (which maybe could be a documentation bug on our side).

> As a side note, the proto code builds perfectly under the 3.7.2 stepancheg release, so maybe this is a bleeding edge problem?

The 4.x release is a complete change compared to 3.x; what happened is that he donated the crate name to Google. So it'll have a whole new set of bugs 🙂

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/protobuf/91bdad1a-1841-4556-9837-6f73c79e8358n%40googlegroups.com.

[Day Rush]

Thank you for a quick and open-minded response!

The possibility that this is an error in my build of some sort is entirely possible: I am hardly an expert in either Rust or protobuf. That said, I have sunk a couple of days into this problem (expensive on a skunkworks project to prove a point) and thought I would ask before I started reading deeply into the compiler code. It is also useful to have that information about the struct/module convention being used. 

I will try and put together an actual minimalist test case before I open the bug. I don't think I can legally use the protos with which I generated the problem, so it might be a day or so before I get around to filing the bug.

- d