Ambiguous associated item lint triggered when an enum member is named 'Error'

[KodrAus]

On rustc 1.81.0-nightly (ed7e35f34 2024-07-06) the following code will trigger the ambiguous_associated_items warning:

#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash, PartialOrd, Ord, ::prost::Enumeration)]
#[repr(i32)]
pub enum SeverityNumber {
    Error = 1,
}

The issue appears to be the generated TryFrom impl:

impl ::core::convert::TryFrom<i32> for SeverityNumber {
    type Error = ::prost::UnknownEnumValue;
    fn try_from(value: i32) -> ::core::result::Result<SeverityNumber, Self::Error> {
        match value {
            1 => ::core::result::Result::Ok(SeverityNumber::Error),
            _ => ::core::result::Result::Err(::prost::UnknownEnumValue(value)),
        }
    }
}

It needs to disambiguate Self::Error:

impl ::core::convert::TryFrom<i32> for SeverityNumber {
    type Error = ::prost::UnknownEnumValue;
    fn try_from(value: i32) -> ::core::result::Result<SeverityNumber, <Self as ::core::convert::TryFrom<i32>>::Error> {
        match value {
            1 => ::core::result::Result::Ok(SeverityNumber::Error),
            _ => ::core::result::Result::Err(::prost::UnknownEnumValue(value)),
        }
    }
}

[poszu]

It happens to me as well on rustc 1.79.0 (prost 0.13.0). It didn't happen on version 0.12.6. It complains for the enum containing Error variant: https://github.com/spacemeshos/api/blob/8b26edc977026717bf2e2085d68dd6d906e63192/spacemesh/v1/post_types.proto#L55-L59

error: ambiguous associated item
   --> /home/bartosz/workspace/post-rs/target/debug/build/service-dc4c9b562e7723d1/out/spacemesh.v1.rs:409:68
    |
409 | #[derive(Clone, Copy, Debug, PartialEq, Eq, Hash, PartialOrd, Ord, ::prost::Enumeration)]
    |                                                                    ^^^^^^^^^^^^^^^^^^^^
note: `Error` could refer to the variant defined here
   --> /home/bartosz/workspace/post-rs/target/debug/build/service-dc4c9b562e7723d1/out/spacemesh.v1.rs:414:5
    |
414 |     Error = 2,
    |     ^^^^^
note: `Error` could also refer to the associated type defined here
   --> /home/bartosz/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/convert/mod.rs:682:5
    |
682 |     type Error;
    |     ^^^^^^^^^^

[rbruenig]

I am running on rustc 1.79.0 (129f3b996 2024-06-10) and having the same issue. Enum in .proto is translated to variant named "Error":

  enum ServiceState {
    SERVICE_STATE_UNSPECIFIED = 0;
    SERVICE_STATE_OK = 1;
    SERVICE_STATE_ERROR = 2;
    SERVICE_STATE_UNAVAILABLE = 3;
  };

which causes

error: ambiguous associated item
   --> ...\baselink\target\debug\build\baselink-api-ceef83970166d2b6\out/baselink.rs:50:9
    |
50  |         ::prost::Enumeration
    |         ^^^^^^^^^^^^^^^^^^^^
    |
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #57644 <https://github.com/rust-lang/rust/issues/57644>
note: `Error` could refer to the variant defined here
   --> ...\baselink\target\debug\build\baselink-api-ceef83970166d2b6\out/baselink.rs:56:9
    |
56  |         Error = 2,
    |         ^^^^^
note: `Error` could also refer to the associated type defined here
   --> ...\toolchains\stable-x86_64-pc-windows-gnu\lib/rustlib/src/rust\library\core\src\convert\mod.rs:682:5
    |
682 |     type Error;
    |     ^^^^^^^^^^
    = note: `#[deny(ambiguous_associated_items)]` on by default
    = note: this error originates in the derive macro `::prost::Enumeration` (in Nightly builds, run with -Z macro-backtrace for more info)

Interestingly even though the warning states that it will become a hard error in the future, it already is a hard error

[caspermeijn]

It seems the generated code uses Self::Error to refer to ::prost::UnknownEnumValue and the term Error is not unique when an enum variant is called Error. I suggest to yank version 0.13.0 and I will create a fix for 0.13.1.

[LucioFranco]

0.13.0 is yanked, and 0.13.1 is on the way.

[LucioFranco]

0.13.1 has been published, thanks for reporting the issue.

[poszu]

0.13.1 has been published, thanks for reporting the issue.

It works perfectly with 0.13.1. Thanks for fixing it quickly ❤️!

[rbruenig]

Can also confirm, works with 0.13.1. You are awesome :)