deprecate `Eq::assert_receiver_is_total_eq` and emit FCW on manual impls #149978

cyrgani · 2025-12-14T09:00:21Z

The Eq::assert_receiver_is_total_eq method is purely meant as an implementation detail by #[derive(Eq)] to add checks that all fields of the type the derive is applied to also implement Eq.
The method is already #[doc(hidden)] and has a comment saying // This should never be implemented by hand..
Unfortunately, it has been stable since 1.0 and there are some cases on GitHub (https://github.com/search?q=assert_receiver_is_total_eq&type=code) where people have implemented this method manually, sometimes even with actual code in the method body (example: https://github.com/Shresht7/codecrafters-redis-rust/blob/31f0ec453c504b4ab053a7b1c3ff548ff36a9db5/src/parser/resp/types.rs#L255).
To prevent further confusion from this, this PR is deprecating the method and adds a FCW when it is manually implemented (this is necessary as the deprecation warning is not emitted when the method is implemented, only when it is called).
This is similar to what was previously done with the soft_unstable lint (#64266).

See also rust-lang/libs-team#704.

rustbot · 2025-12-14T09:00:25Z

r? @madsmtm

rustbot has assigned @madsmtm.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

cyrgani · 2025-12-14T09:01:07Z

compiler/rustc_lint/src/builtin.rs

+    Warn,
+    "manual implementation of the internal `Eq::assert_receiver_is_total_eq` method",
+    @future_incompatible = FutureIncompatibleInfo {
+        reason: fcw!(FutureReleaseError #150000),


TODO: create a real tracking issue once there is consensus on this change

madsmtm

Implementation looks good, feel free to r=me on that once you have t-libs signoff (FCP?).

Procedurally, this might also need t-lang approval for the lint name IIUC? Or can t-libs decide that?

View changes since this review

Amanieu · 2026-01-06T18:35:24Z

Since there's never a valid reason to manually implement this method, having an FCW urging people to remove their manual implementation seems like the best way to go.

@rfcbot merge libs-api lang

rust-rfcbot · 2026-01-06T18:35:26Z

Error encounted:
Provided team libs-api lang is invalid

Amanieu · 2026-01-06T18:36:47Z

@rfcbot merge

rust-rfcbot · 2026-01-06T18:36:49Z

Error encounted:
Provided team `` is invalid

Amanieu · 2026-01-06T18:37:08Z

@rfcbot merge libs-api,lang

rust-rfcbot · 2026-01-06T18:37:09Z

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

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

dtolnay · 2026-01-06T18:53:59Z

Since there's never a valid reason to manually implement this method, having an FCW urging people to remove their manual implementation seems like the best way to go.

I don't agree with this. The reason is the same reason that the standard library's derived Eq implementations implement this method. If someone has their own Eq derive macro (e.g. the derive_more use case) they would want to do the same thing.

I am open to deprecating the method, but I would not want to do so while derive(Eq) is continuing to use it. We should first change derive(Eq) to use some other approach. Then, when we deprecate, custom Eq derive macros can mirror the standard library's approach.

dtolnay · 2026-01-06T18:57:53Z

Ah, relevant line:

rust/compiler/rustc_lint/src/builtin.rs

Line 3244 in 81dc07d

&& !item.span.from_expansion()

"Manual" means not from a macro expansion. Then this seems fine.

In the longer term, I would prefer to fully deprecate assert_receiver_is_total_eq including for macro expansions.

Amanieu · 2026-01-07T12:37:15Z

assert_receiver_is_total_eq only exists because the derive needs a body in which to put static assertions (that the struct members all implement Eq). Back in 1.0, this was the only that this could be done. Today, you could do this by having the derive emit something like:

const _: () = {
    fn assert_receiver_is_total_eq<Generics>() {
        ..
    }
};

So even custom derives of Eq do not need this method any more.

compiler/rustc_lint/src/builtin.rs

traviscross · 2026-01-08T07:27:01Z

compiler/rustc_lint/src/builtin.rs

+impl<'tcx> LateLintPass<'tcx> for EqAssertReceiverIsTotalEq {
+    fn check_impl_item(&mut self, cx: &LateContext<'tcx>, item: &'tcx rustc_hir::ImplItem<'tcx>) {
+        if let ImplItemImplKind::Trait { defaultness: _, trait_item_def_id: Ok(trait_item_def_id) } =
+            item.impl_kind
+            && item.ident.name == sym::assert_receiver_is_total_eq
+            && cx.tcx.is_diagnostic_item(sym::assert_receiver_is_total_eq, trait_item_def_id)
+            && !item.span.from_expansion()
+        {
+            cx.emit_span_lint(
+                EQ_ASSERT_RECEIVER_IS_TOTAL_EQ_IMPL,
+                item.span,
+                EqInternalMethodImplemented,
+            );
+        }
+    }
+}


I gather this !item.span.from_expansion() check suppresses the lint for impls from all macro expansions, i.e. even for user-defined macros. Given that we want to catch as much as possible so as to be able to make this into an error, perhaps a more strict check is in order?

I updated the lint to fire in every case and added an explicit #[allow(internal_eq_trait_method_impls)] to the method generated by derive(Eq).

rustbot · 2026-01-08T07:35:38Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

rustbot · 2026-01-08T12:18:25Z

Changes to the code generated for builtin derived traits.

cc @nnethercote

rustbot · 2026-01-08T12:18:27Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

…impls

traviscross

Looks good to me modulo the marked TODOs.

@rfcbot reviewed

View changes since this review

rust-bors · 2026-01-13T14:36:43Z

☔ The latest upstream changes (presumably #151051) made this pull request unmergeable. Please resolve the merge conflicts.

rustbot assigned madsmtm Dec 14, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 14, 2025

cyrgani commented Dec 14, 2025

View reviewed changes

This comment has been minimized.

Sign in to view

rust-cloud-vms bot force-pushed the no-eq-assert-receiver-method branch from faf29de to 81dc07d Compare December 14, 2025 11:30

madsmtm changed the title ~~deprecate Eq::assert_receiver_is_total_eq and emit a FCW on manual …~~ deprecate Eq::assert_receiver_is_total_eq and emit FCW on manual impls Dec 14, 2025

madsmtm reviewed Dec 14, 2025

View reviewed changes

madsmtm added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 14, 2025

cyrgani added I-lang-nominated Nominated for discussion during a lang team meeting. I-libs-nominated Nominated for discussion during a libs team meeting. labels Dec 14, 2025

rust-rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Jan 6, 2026

Amanieu removed the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Jan 6, 2026

traviscross requested changes Jan 8, 2026

View reviewed changes

rust-cloud-vms bot force-pushed the no-eq-assert-receiver-method branch from 81dc07d to 62743e8 Compare January 8, 2026 12:18

This comment has been minimized.

Sign in to view

deprecate Eq::assert_receiver_is_total_eq and emit a FCW on manual …

4ee1588

…impls

rust-cloud-vms bot force-pushed the no-eq-assert-receiver-method branch from 62743e8 to 4ee1588 Compare January 8, 2026 14:36

traviscross approved these changes Jan 8, 2026

View reviewed changes

Uh oh!

deprecate Eq::assert_receiver_is_total_eq and emit FCW on manual impls #149978

Are you sure you want to change the base?

deprecate Eq::assert_receiver_is_total_eq and emit FCW on manual impls #149978

Uh oh!

Conversation

cyrgani commented Dec 14, 2025 • edited by madsmtm Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Dec 14, 2025

Uh oh!

cyrgani Dec 14, 2025

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

madsmtm left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Amanieu commented Jan 6, 2026

Uh oh!

rust-rfcbot commented Jan 6, 2026

Uh oh!

Amanieu commented Jan 6, 2026

Uh oh!

rust-rfcbot commented Jan 6, 2026

Uh oh!

Amanieu commented Jan 6, 2026

Uh oh!

rust-rfcbot commented Jan 6, 2026 • edited by traviscross Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dtolnay commented Jan 6, 2026

Uh oh!

dtolnay commented Jan 6, 2026

Uh oh!

Amanieu commented Jan 7, 2026

Uh oh!

Uh oh!

traviscross Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cyrgani Jan 8, 2026

Choose a reason for hiding this comment

Uh oh!

rustbot commented Jan 8, 2026

Uh oh!

rustbot commented Jan 8, 2026

Uh oh!

rustbot commented Jan 8, 2026

Uh oh!

This comment has been minimized.

traviscross left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rust-bors bot commented Jan 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

deprecate `Eq::assert_receiver_is_total_eq` and emit FCW on manual impls #149978

deprecate `Eq::assert_receiver_is_total_eq` and emit FCW on manual impls #149978

cyrgani commented Dec 14, 2025 •

edited by madsmtm

Loading

madsmtm left a comment •

edited

Loading

rust-rfcbot commented Jan 6, 2026 •

edited by traviscross

Loading

traviscross Jan 8, 2026 •

edited

Loading

traviscross left a comment •

edited by rustbot

Loading