Tracking issue for overlapping_inherent_impls compatibility lint

[petrochenkov]

UPDATE: We've decided to convert this warning into a hard error, but are still waiting for a PR to make that a reality. If you're interested in contributing, there are directions for writing such a PR available here.

This tracking issue pertains to a bug fix for #22889. The problem was that the compiler was accepting two inherent impls that both defined the same method, which creates an obvious ambiguity:

struct Foo;

impl Foo {
    fn id() {}
}

impl Foo {
    fn id() {}
}

The most obvious fix here is to give one method a distinct name, though sometimes there are other possible rewrites (e.g., one could rewrite the impls to use a double dispatch pattern).

Current status

• Forbid items with the same name from appearing in overlapping inherent impl blocks #31925 introduces the overlapping_inherent_impls lint as warn-by-default
• Make sufficiently old or low-impact compatibility lints deny-by-default #36894 makes the overlapping_inherent_impls lint deny-by-default
• PR ? makes the overlapping_inherent_impls lint a hard error

[petrochenkov]

@aturon , could you write a description for this?

[QuietMisdreavus]

#38967 could be related to this.

[nikomatsakis]

@rfcbot fcp merge

This warning has been out for a while. I propose we move it to deny-by-default.

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams:

• @Aatch
• @arielb1
• @bkoropoff
• @dotdash
• @eddyb
• @michaelwoerister
• @nikomatsakis
• @nrc
• @pnkfelix

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[petrochenkov]

@nikomatsakis

I propose we move it to deny-by-default.

There's a catch.
It's already deny-by-default for almost 4 months.

[nikomatsakis]

@petrochenkov heh =) Um, d'oh! Then I propose we kill it. I'll start again. :)

[nikomatsakis]

@rfcbot fcp cancel

[rfcbot]

@nikomatsakis proposal cancelled.

[nikomatsakis]

@rfcbot fcp merge

This warning has been deny-by-default for a while. I propose we move it to a hard error.

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams:

• @Aatch
• @arielb1
• @bkoropoff
• @dotdash
• @eddyb
• @michaelwoerister
• @nikomatsakis
• @nrc
• @pnkfelix

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period is now complete.

[aturon]

cc @petrochenkov @rust-lang/compiler -- anyone want to make a quick stabilization PR that we can backport to 1.17 beta?

[nikomatsakis]

This seems like a good first bug. I wrote up some directions and posted them to forge for converting compatibility lints into hard errors. The descriptions probably haven't landed yet, but here is the PR:

rust-lang/rust-forge#48

Marking a E-easy and E-mentor, the directions are in that PR. =)

[topecongiro]

Hello, I would like to work on this if no one is interested.

[nikomatsakis]

@topecongiro go for it:)

[nikomatsakis]

@topecongiro please feel free to ping me on irc (nmatsakis) if you encounter any difficulty...

[topecongiro]

@nikomatsakis Thank you!