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

tonic-build: Codegen generates a name collision after auto-capitalization is applied, resulting in cargo build errors #1691

Open
zenithlight opened this issue Apr 26, 2024 · 0 comments

Comments

@zenithlight
Copy link

Bug Report

Version

└── tonic v0.11.0
└── tonic-build v0.11.0

Platform

Linux enceladus 5.15.146.1-microsoft-standard-WSL2 #1 SMP Thu Jan 11 04:09:03 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Crates

tonic-build

Description

I'm trying to build protos for Cosmos using tonic-build.

One of the proto files contains both names validators and Validators:

message StakeAuthorization {
  option (cosmos_proto.implements_interface) = "cosmos.authz.v1beta1.Authorization";
  option (amino.name)                        = "cosmos-sdk/StakeAuthorization";

  // max_tokens specifies the maximum amount of tokens can be delegate to a validator. If it is
  // empty, there is no spend limit and any amount of coins can be delegated.
  cosmos.base.v1beta1.Coin max_tokens = 1 [(gogoproto.castrepeated) = "github.com/cosmos/cosmos-sdk/types.Coin"];
  // validators is the oneof that represents either allow_list or deny_list
  oneof validators {
    // allow_list specifies list of validator addresses to whom grantee can delegate tokens on behalf of granter's
    // account.
    Validators allow_list = 2 [(amino.oneof_name) = "cosmos-sdk/StakeAuthorization/AllowList"];
    // deny_list specifies list of validator addresses to whom grantee can not delegate tokens.
    Validators deny_list = 3 [(amino.oneof_name) = "cosmos-sdk/StakeAuthorization/DenyList"];
  }
  // Validators defines list of validator addresses.
  message Validators {
    repeated string address = 1 [(cosmos_proto.scalar) = "cosmos.AddressString"];
  }
  // authorization_type defines one of AuthorizationType.
  AuthorizationType authorization_type = 4;
}

Because of auto-capitalization, the generated Rust includes two types both with the name Validators:

/// Nested message and enum types in `StakeAuthorization`.
pub mod stake_authorization {
    /// Validators defines list of validator addresses.
    #[allow(clippy::derive_partial_eq_without_eq)]
    #[derive(Clone, PartialEq, ::prost::Message)]
    pub struct ValidatorList {
        #[prost(string, repeated, tag = "1")]
        pub address: ::prost::alloc::vec::Vec<::prost::alloc::string::String>,
    }
    /// validators is the oneof that represents either allow_list or deny_list
    #[allow(clippy::derive_partial_eq_without_eq)]
    #[derive(Clone, PartialEq, ::prost::Oneof)]
    pub enum Validators {
        /// allow_list specifies list of validator addresses to whom grantee can delegate tokens on behalf of granter's
        /// account.
        #[prost(message, tag = "2")]
        AllowList(Validators),
        /// deny_list specifies list of validator addresses to whom grantee can not delegate tokens.
        #[prost(message, tag = "3")]
        DenyList(Validators),
    }
}

This causes cargo build to fail with errors:

error[E0428]: the name `Validators` is defined multiple times
  --> /home/lumi/code/rust-dydx-protos/target/debug/build/rust-dydx-protos-2059e937180aa0c5/out/cosmos.staking.v1beta1.rs:31:5
   |
24 |     pub struct Validators {
   |     --------------------- previous definition of the type `Validators` here
...
31 |     pub enum Validators {
   |     ^^^^^^^^^^^^^^^^^^^ `Validators` redefined here
   |
   = note: `Validators` must be defined only once in the type namespace of this module

By monkey patching the .proto to use the name ValidatorList instead of Validators I can get the build to succeed. But I'm wondering if there is any solution within tonic-build to deal with this.

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

1 participant