diff options
| author | bors <bors@rust-lang.org> | 2022-08-18 10:11:11 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2022-08-18 10:11:11 +0000 |
| commit | 361c599feeefaf6e50efd90658fc9c2222154684 (patch) | |
| tree | 4db3cd0ce9547ceaba845cd670ac8c7c71acd430 /compiler/rustc_macros | |
| parent | f241c0c43d71960f078b897e9b8721d4b452ce5e (diff) | |
| parent | d4a5b034b75c7ea3d9a7955857f56ecc7d7b9cca (diff) | |
| download | rust-361c599feeefaf6e50efd90658fc9c2222154684.tar.gz rust-361c599feeefaf6e50efd90658fc9c2222154684.zip | |
Auto merge of #98655 - nnethercote:dont-derive-PartialEq-ne, r=dtolnay
Don't derive `PartialEq::ne`. Currently we skip deriving `PartialEq::ne` for C-like (fieldless) enums and empty structs, thus reyling on the default `ne`. This behaviour is unnecessarily conservative, because the `PartialEq` docs say this: > Implementations must ensure that eq and ne are consistent with each other: > > `a != b` if and only if `!(a == b)` (ensured by the default > implementation). This means that the default implementation (`!(a == b)`) is always good enough. So this commit changes things such that `ne` is never derived. The motivation for this change is that not deriving `ne` reduces compile times and binary sizes. Observable behaviour may change if a user has defined a type `A` with an inconsistent `PartialEq` and then defines a type `B` that contains an `A` and also derives `PartialEq`. Such code is already buggy and preserving bug-for-bug compatibility isn't necessary. Two side-effects of the change: - There is only one error message produced for types where `PartialEq` cannot be derived, instead of two. - For coverage reports, some warnings about generated `ne` methods not being executed have disappeared. Both side-effects seem fine, and possibly preferable.
Diffstat (limited to 'compiler/rustc_macros')
0 files changed, 0 insertions, 0 deletions
