Skip to content
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

Recursive PartialEq implementation not detected #99220

Open
5225225 opened this issue Jul 13, 2022 · 2 comments
Open

Recursive PartialEq implementation not detected #99220

5225225 opened this issue Jul 13, 2022 · 2 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@5225225
Copy link
Contributor

5225225 commented Jul 13, 2022

Given the following code: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=ed9fb2f62239c9485d43d48e3e0d419b

struct Foo(u32);

impl std::cmp::PartialEq for Foo {
    fn eq(&self, rhs: &Self) -> bool {
        self == rhs
    }
}

The current output is:

(no warnings)

Ideally the output should look like:

warning: function cannot return without recursing
 --> src/lib.rs:4:5
  |
4 |     fn eq(&self, rhs: &Self) -> bool {
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot return without recursing
5 |         self == rhs
  |         ----------- recursive call site
  |
  = note: `#[warn(unconditional_recursion)]` on by default
  = help: a `loop` may express intention better if this is on purpose

Note how we do warn about this if you do self.eq(rhs). So I guess it's a matter of treating == as .eq for the purposes of recursion checking? Not sure.

Happens on nightly/beta/stable.

@5225225 5225225 added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 13, 2022
@tmiasko
Copy link
Contributor

tmiasko commented Jul 13, 2022

See also #57299 (comment) and #57965.

@5225225
Copy link
Contributor Author

5225225 commented Jul 13, 2022

Ah, couldn't find those.

That being said, I think a special case for this body in particular might be worthwhile for as long as we don't have a more general solution, since I've seen people do it more than a few times.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants