Skip to content

fix(#141141): When expanding PartialEq, check equality of scalar types first. #141724

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 3, 2025

Conversation

Sol-Ell
Copy link
Contributor

@Sol-Ell Sol-Ell commented May 29, 2025

Fixes #141141.

Now, cs_eq function of partial_eq.rs compares scalar types first.

  • Add is_scalar field to FieldInfo.
  • Add is_scalar method to TyKind.
  • Pass FieldInfo via CsFold::Combine and refactor code relying on it.
  • Implement TryFrom<&str> and TryFrom<Symbol> for FloatTy.
  • Implement TryFrom<&str> and TryFrom<Symbol> for IntTy.
  • Implement TryFrom<&str> and TryFrom<Symbol> for UintTy.

@rustbot
Copy link
Collaborator

rustbot commented May 29, 2025

r? @oli-obk

rustbot has assigned @oli-obk.
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

@rustbot 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. labels May 29, 2025
@rust-log-analyzer

This comment has been minimized.

@Sol-Ell Sol-Ell force-pushed the issue-141141-fix branch from 6e72625 to 3f53218 Compare May 29, 2025 14:25
@rustbot
Copy link
Collaborator

rustbot commented May 29, 2025

Changes to the code generated for builtin derived traits.

cc @nnethercote

@Sol-Ell Sol-Ell force-pushed the issue-141141-fix branch from 3f53218 to e640d3d Compare May 29, 2025 14:31
@Sol-Ell Sol-Ell force-pushed the issue-141141-fix branch from e640d3d to 843083a Compare May 30, 2025 09:09
self.b2 == other.b2 && self.b4 == other.b4 && self.b5 == other.b5 &&
self.b6 == other.b6 && self.b7 == other.b7 &&
self.b8 == other.b8 && self.b10 == other.b10 &&
(self.b1 == other.b1 && self.b3 == other.b3 && self._b == other._b
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can these parentheses be avoided? They're not necessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Parentheses are generated because the comparison expressions for scalar and compound fields are grouped and then combined in a single pass. As far as I understand, removing these parentheses would require iterating over the fields twice: once to collect all scalar-typed fields, and a second time to add the comparisons for compound-typed fields. Would making two passes over the fields be acceptable for this purpose?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two passes sounds fine, the number of fields is always small so the performance effect should be negligible.

(ReorderEnum::G(__self_0, __self_1, __self_2),
ReorderEnum::G(__arg1_0, __arg1_1, __arg1_2)) =>
__self_1 == __arg1_1 &&
(__self_0 == __arg1_0 && __self_2 == __arg1_2),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can these parens be avoided?

@oli-obk oli-obk assigned nnethercote and unassigned oli-obk May 30, 2025
@Sol-Ell Sol-Ell force-pushed the issue-141141-fix branch from 843083a to 12c73a9 Compare May 30, 2025 15:34
@nnethercote nnethercote 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 May 30, 2025
@Sol-Ell Sol-Ell force-pushed the issue-141141-fix branch from 12c73a9 to 235b472 Compare May 31, 2025 09:25
Copy link
Contributor

@nnethercote nnethercote left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good, just a few nits to fix. Thanks.

@rustbot author

@@ -2452,6 +2452,32 @@ impl TyKind {
None
}
}

pub fn maybe_scalar(&self) -> bool {
let Some(ty_kind) = self.is_simple_path() else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ty_sym would be a better name than ty_kind. I was momentarily confused because I thought this would have TyKind.

@@ -2452,6 +2452,32 @@ impl TyKind {
None
}
}

pub fn maybe_scalar(&self) -> bool {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A brief comment explaining the maybe_ prefix would be good, i.e. that it's not perfectly accurate because of typedefs.

#[inline]
fn partial_cmp(&self, other: &Reorder)
-> ::core::option::Option<::core::cmp::Ordering> {
match ::core::cmp::PartialOrd::partial_cmp(&self.b1, &other.b1) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Scalars are being checked first for eq. But partial_cmp is still using the old field ordering. Is this intentional?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And likewise for the enum case below.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optimizing partial_cmp while keeping its guarantees would require a separate issue. This PR focuses on the PartialEq::eq.


/// Generates the equality expression for a struct or enum variant when deriving `PartialEq`.
///
/// This function generates an expression that checks if all fields of a struct or enum variant are equal.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few lines exceed 100 chars, please reflow the comments.

@rustbot
Copy link
Collaborator

rustbot commented Jun 2, 2025

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

@Sol-Ell Sol-Ell force-pushed the issue-141141-fix branch from 235b472 to a6a1c1b Compare June 2, 2025 12:33
@Sol-Ell
Copy link
Contributor Author

Sol-Ell commented Jun 2, 2025

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 2, 2025
@nnethercote
Copy link
Contributor

Thank you!

@bors r+

@bors
Copy link
Collaborator

bors commented Jun 3, 2025

📌 Commit a6a1c1b has been approved by nnethercote

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 3, 2025
bors added a commit that referenced this pull request Jun 3, 2025
Rollup of 8 pull requests

Successful merges:

 - #141724 (fix(#141141): When expanding `PartialEq`, check equality of scalar types first.)
 - #141833 (`tests/ui`: A New Order [2/N])
 - #141861 (Switch `x86_64-msvc-{1,2}` back to Windows Server 2025 images)
 - #141914 (redesign stage 0 std follow-ups)
 - #141918 (Deconstruct values in the THIR visitor)
 - #141923 (Update books)
 - #141931 (Deconstruct values in the THIR visitor)
 - #141956 (Remove two trait methods from cg_ssa)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 1943766 into rust-lang:master Jun 3, 2025
10 checks passed
@rustbot rustbot added this to the 1.89.0 milestone Jun 3, 2025
rust-timer added a commit that referenced this pull request Jun 3, 2025
Rollup merge of #141724 - Sol-Ell:issue-141141-fix, r=nnethercote

fix(#141141): When expanding `PartialEq`, check equality of scalar types first.

Fixes #141141.

Now, `cs_eq` function of `partial_eq.rs` compares [scalar types](https://doc.rust-lang.org/rust-by-example/primitives.html#scalar-types) first.

- Add `is_scalar` field to `FieldInfo`.
- Add `is_scalar` method to `TyKind`.
- Pass `FieldInfo` via `CsFold::Combine` and refactor code relying on it.
- Implement `TryFrom<&str>` and `TryFrom<Symbol>` for FloatTy.
- Implement `TryFrom<&str>` and `TryFrom<Symbol>` for IntTy.
- Implement `TryFrom<&str>` and `TryFrom<Symbol>` for UintTy.
@Sol-Ell Sol-Ell deleted the issue-141141-fix branch June 5, 2025 09:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

#[derive(PartialEq)] does not reorder field comparisons to improve performance
7 participants