Skip to content

incorrect unstable_name_collision warning for unstable inherent method name #50232

Description

@tspiteri

Compiling the code below with nightly produces an unstable_name_collision warning. However the code works after enabling the feature gate, I presume because the unstable method is inherent and takes precedence over trait methods. In this particular case, it can still be worth warning that the behaviour of the standard library method can be different, but the current “warning: once this method is added to the standard library, there will be ambiguity here, which will cause a hard error!” is incorrect.

//#![feature(euclidean_division)]
trait DivEuc {
    fn div_euc(self, rhs: Self) -> Self;
}
impl DivEuc for u32 {
    fn div_euc(self, rhs: Self) -> Self { self / rhs }
}
fn main() {
    println!("{}", 12u32.div_euc(3));
}

Activity

  1. added
    C-enhancementCategory: An issue proposing an enhancement or a PR with one.
    A-diagnosticsArea: Messages for errors, warnings, and lints
    T-libs-api[DEPRECATED; DO NOT USE]
    on Apr 26, 2018
  2. varkor commented on Apr 26, 2018

    @varkor
    Contributor

    cc @kennytm, as this lint comes from #48552.

  3. added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    A-docsArea: Documentation for any part of the project, including the compiler, standard library, and tools
    and removed
    T-libs-api[DEPRECATED; DO NOT USE]
    on Apr 26, 2018
  4. kennytm commented on Apr 26, 2018

    @kennytm
    Member

    What about this?

    warning: once this method is added to the standard library, there will be ambiguity here, which will cause a hard error or change of behavior!

    It seems the message is too long though.

  5. varkor commented on Apr 26, 2018

    @varkor
    Contributor

    Or simply:

    warning: once this method is added to the standard library, the ambiguity may cause an error or change in behaviour!

    (which is even shorter than the original.)

  6. tspiteri commented on Apr 26, 2018

    @tspiteri
    ContributorAuthor

    If the trait method parameters are different from the inherent method parameters, it could end up leading to a hard error for a different reason. For example for the code below, opening the feature gate will cause a hard error, but because of a type mismatch rather than because of ambiguity.

    //#![feature(euclidean_division)]
    trait DivEuc {
        fn div_euc(self, rhs: u8) -> Self;
    }
    impl DivEuc for u32 {
        fn div_euc(self, rhs: u8) -> Self { self / rhs as u32 }
    }
    fn main() {
        println!("{}", 12u32.div_euc(3u8));
    }

    So a more generic error like @varkor suggests is better.

  7. self-assigned this
    on Apr 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-diagnosticsArea: Messages for errors, warnings, and lintsA-docsArea: Documentation for any part of the project, including the compiler, standard library, and toolsC-enhancementCategory: An issue proposing an enhancement or a PR with one.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions