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

Invalid generated code when using a nested message with a map field #843

Closed
FoxLisk opened this issue Apr 16, 2023 · 1 comment · Fixed by #981
Closed

Invalid generated code when using a nested message with a map field #843

FoxLisk opened this issue Apr 16, 2023 · 1 comment · Fixed by #981

Comments

@FoxLisk
Copy link

FoxLisk commented Apr 16, 2023

Using a protobuf file with these contents:

syntax = "proto3";
message M {
  message SubMessage {
    map<string, string> item = 1;
  }
  SubMessage reply = 2;
}

I'm getting invalid code:

#[allow(clippy::derive_partial_eq_without_eq)]
#[derive(Clone, PartialEq, ::prost::Message)]
pub struct M {
    #[prost(message, optional, tag = "2")]
    pub reply: ::core::option::Option<m::SubMessage>,
}
/// Nested message and enum types in `M`.
pub mod m {
    #[allow(clippy::derive_partial_eq_without_eq)]
    #[derive(Clone, PartialEq, ::prost::Message)]
    pub struct SubMessage {
        #[prost(message, repeated, tag = "1")]
        pub item: ::prost::alloc::vec::Vec<sub_message::ItemEntry>,
    }
}

the error:

error[E0433]: failed to resolve: use of undeclared crate or module `sub_message`
  --> D:\code\sni_things\target\debug\build\sni_things-e5c2e47c00096f71\out/_.rs:13:44
   |
13 |         pub item: ::prost::alloc::vec::Vec<sub_message::ItemEntry>,
   |                                            ^^^^^^^^^^^ use of undeclared crate or module `sub_message`

This works if I change the map in the proto definition into a scalar, or if I move SubMessage out of M (so it's no longer nested). (of course in real life I don't control the protobuf file, so this solution doesn't work very well).

@hsyan2008
Copy link

I have the same problem

caspermeijn added a commit to caspermeijn/prost that referenced this issue Feb 28, 2024
When package name is empty, but type_path is filled, the fq_message_name should begin with a single dot.

Two duplicate implementations are moved to a separate function.

A test is added that creates a sub message without a package name. The code generator uses the message name to generate a rust module path, which is invalid.

fixes: tokio-rs#843
LucioFranco pushed a commit that referenced this issue Feb 28, 2024
When package name is empty, but type_path is filled, the fq_message_name should begin with a single dot.

Two duplicate implementations are moved to a separate function.

A test is added that creates a sub message without a package name. The code generator uses the message name to generate a rust module path, which is invalid.

fixes: #843
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants