Repository navigation
Open
Labels
C-bugCategory: Clippy is not doing the correct thingCategory: Clippy is not doing the correct thingI-false-positiveIssue: The lint was triggered on code it shouldn't haveIssue: The lint was triggered on code it shouldn't haveI-suggestion-causes-errorIssue: The suggestions provided by this Lint cause an ICE/error when appliedIssue: The suggestions provided by this Lint cause an ICE/error when appliedL-nurseryLint: Currently in the nursery groupLint: Currently in the nursery groupS-triageStatus: PR was triaged and is waiting for an action from a maintainer (closing/moving/... the PR)Status: PR was triaged and is waiting for an action from a maintainer (closing/moving/... the PR)
Description
Summary
.
Lint Name
derive_partial_eq_without_eq
Reproducer
I tried this code:
Unfortunately I have no idea what is happening here :/
#![feature(decl_macro)]
#[derive(Copy, Clone, PartialEq, Debug)]
pub enum Field {
RootCtxt,
MacroCtxt,
}
#[rustfmt::skip]
macro x(
$macro_name:ident,
$macro2_name:ident,
$type_name:ident,
$field_name:ident,
$const_name:ident
) {
#[derive(Copy, Clone)]
pub struct $type_name {
pub field: Field,
pub $field_name: Field,
}
pub const $const_name: $type_name =
$type_name { field: Field::MacroCtxt, $field_name: Field::RootCtxt };
#[macro_export]
macro_rules! $macro_name {
(check_fields_of $e:expr) => {{
let e = $e;
assert_eq!(e.field, Field::MacroCtxt);
assert_eq!(e.$field_name, Field::RootCtxt);
}};
(check_fields) => {{
assert_eq!($const_name.field, Field::MacroCtxt);
assert_eq!($const_name.$field_name, Field::RootCtxt);
}};
(construct) => {
$type_name { field: Field::MacroCtxt, $field_name: Field::RootCtxt }
};
}
pub macro $macro2_name {
(check_fields_of $e:expr) => {{
let e = $e;
assert_eq!(e.field, Field::MacroCtxt);
assert_eq!(e.$field_name, Field::RootCtxt);
}},
(check_fields) => {{
assert_eq!($const_name.field, Field::MacroCtxt);
assert_eq!($const_name.$field_name, Field::RootCtxt);
}},
(construct) => {
$type_name { field: Field::MacroCtxt, $field_name: Field::RootCtxt }
}
}
}
x!(test_fields, test_fields2, MyStruct, field, MY_CONST);
pub fn check_fields(s: MyStruct) {
test_fields!(check_fields_of s);
}
pub fn main() {}I saw this happen:
cargo clippy --fix -- -Aclippy::all -Wclippy::derive_partial_eq_without_eq
Checking clpy v0.1.0 (/tmp/clpy)
warning: failed to automatically apply fixes suggested by rustc to crate `clpy`
after fixes were automatically applied the compiler reported errors within these files:
* src/main.rs
This likely indicates a bug in either rustc or cargo itself,
and we would appreciate a bug report! You're likely to see
a number of compiler warnings after this message which cargo
attempted to fix but failed. If you could open an issue at
https://github.com/rust-lang/rust/issues
quoting the full output of this command we'd be very appreciative!
Note that you may be able to make some more progress in the near-term
fixing code with the `--broken-code` flag
The following errors were reported:
error[E0609]: no field `field` on type `MyStruct`
--> src/main.rs:30:26
|
30 | assert_eq!(e.field, Field::MacroCtxt);
| ^^^^^ help: a field with a similar name exists: `field`
...
61 | test_fields!(check_fields_of s);
| ------------------------------- in this macro invocation
|
= note: this error originates in the macro `test_fields` (in Nightly builds, run with -Z macro-backtrace for more info)
error: aborting due to previous error
For more information about this error, try `rustc --explain E0609`.
Original diagnostics will follow.
warning: you are deriving `PartialEq` and can implement `Eq`
--> src/main.rs:3:23
|
3 | #[derive(Copy, Clone, PartialEq, Debug)]
| ^^^^^^^^^ help: consider deriving `Eq` as well: `PartialEq, Eq`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#derive_partial_eq_without_eq
= note: requested on the command line with `-W clippy::derive-partial-eq-without-eq`
warning: `clpy` (bin "clpy") generated 1 warning (run `cargo fix --bin "clpy"` to apply 1 suggestion)
warning: `clpy` (bin "clpy" test) generated 1 warning
Version
rustc 1.67.0-nightly (c5d82ed7a 2022-11-19)
binary: rustc
commit-hash: c5d82ed7a4ad94a538bb87e5016e7d5ce0bd434b
commit-date: 2022-11-19
host: x86_64-unknown-linux-gnu
release: 1.67.0-nightly
LLVM version: 15.0.4
Additional Labels
No response
Metadata
Metadata
Assignees
Labels
C-bugCategory: Clippy is not doing the correct thingCategory: Clippy is not doing the correct thingI-false-positiveIssue: The lint was triggered on code it shouldn't haveIssue: The lint was triggered on code it shouldn't haveI-suggestion-causes-errorIssue: The suggestions provided by this Lint cause an ICE/error when appliedIssue: The suggestions provided by this Lint cause an ICE/error when appliedL-nurseryLint: Currently in the nursery groupLint: Currently in the nursery groupS-triageStatus: PR was triaged and is waiting for an action from a maintainer (closing/moving/... the PR)Status: PR was triaged and is waiting for an action from a maintainer (closing/moving/... the PR)
Activity
ada4a commentedon Aug 30, 2025
It's bizarre to me that this compiles in the first place, given that this part of the
x!macro defintion:with
x!being invoked with the following parameters:should result in the following:
(and in fact does, if you believe Playground's "Expand macros" functionality: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=61e03ea293b35d55b2f2b7fe2b0b11aa), which obviously wouldn't compile if written out by hand.
But it looks like, for some reason, no error is emitted unless you try to e.g. construct an instance of
MyStructinmain. Furthermore, no error is emitted even if you add a function like:But that's apparently only because
fieldins.fieldgets resolved to the second field namedfield! Because if you change thex!invocation to the following:Then
fooactually stops compiling!I'm not sure what exactly on the Clippy side surfaces this error, but I'm convinced that the actual problem here is that the error doesn't surface earlier, which I'd say is more of a rustc bug. So maybe transfer this issue there?
@rustbot label S-triage