Tracking Issue for future-incompatibility lint `internal_eq_trait_method_impls`
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.2k
- PR merge metrics
- PR metrics pending
Description
This is the tracking issue for the internal_eq_trait_method_impls future-compatibility warning and other related errors. The goal of this page is to describe why this change was made and how you can fix code that is affected by it. It also provides a place to ask questions or register a complaint if you feel the change should not be made. For more information on the policy around future-compatibility warnings, see our breaking change policy guidelines.
What is the warning for?
The Eq trait has the internal, undocumented helper method assert_receiver_is_total_eq. It was never meant to be implemented by anyone except for the expansion of #[derive(Eq)]. The internal_eq_trait_method_impls lint will issue a warning for any other implementations of this method.
Why was this change made?
The method dates back to the 1.0 release of Rust. Since then, it has gotten new syntax like const _ that will allow the derive macro to no longer need this method. There have also been cases where IDEs detected the presence of the method and automatically added a useless default implementation of the method. To prevent further confusion from this, this future-compatibility warning was added.
The lang and libs-api teams approved this lint in https://github.com/rust-lang/rust/pull/149978#issuecomment-3715850489.
Example
#[derive(PartialEq)]
pub struct Foo;
impl Eq for Foo {
fn assert_receiver_is_total_eq(&self) {}
}
Recommendations
Remove any manual implementations of the method and just write impl Eq for Foo {}.
When will this warning become a hard error?
Unknown
Steps
- Implement the lint (#149978)
- Raise lint level to deny
- Change the lint to report in dependencies
- Switch to a hard error
Implementation history
- #149978
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the warning rationale, recommendations, and implementation history linked from tracking issue #152336, then inspect implementation PR #149978. Done would require resolving the remaining checklist items: raising the lint level to deny, reporting it in dependencies, and switching it to a hard error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100