Skip to content

Addresses #1955 - Suggests >= y + 1 become > y #2060

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 7 commits into from
Sep 24, 2017

Conversation

mrecachinas
Copy link

@mrecachinas mrecachinas commented Sep 17, 2017

This is a first pass, and as such, doesn't address a few cases (illustrated below).

This module handles the following cases:

  • ... >= ... + 1 and ... >= 1 + ...
  • ... - 1 >= ... and -1 + ... >= ...
  • ... + 1 <= ... and ... + 1 <= ...
  • ... <= ... - 1 and ... <= -1 + ...

Note: this only goes 1 level deep (i.e., does not constant-fold or
perform constant propagation) and does not currently simplify
expressions.

Examples of these cases include:

let x = 1;
y >= y + x; // won't catch this case or any permutation

x + 1 >= y + 2; // won't catch this case

x + 1 - 1 >= y - 1 + 1; // WILL catch this case when it likely shouldn't

Interested in your thoughts and suggestions. :)

Michael Recachinas added 3 commits September 17, 2017 17:18
This module handles the following cases:
- `... >= ... + 1` and `... >= 1 + ...`
- `... - 1 >= ...` and `-1 + ... >= ...`
- `... + 1 <= ...` and `... + 1 <= ...`
- `... <= ... - 1` and `... <= -1 + ...`

Note: this only goes 1 level deep (i.e., does not constant-fold) and
does not currently simplify expressions. Examples of these
cases include:
```rust
let x = 1;
y >= y + x; // won't catch this case or any permutation

x + 1 >= y + 2; // won't catch this case

x + 1 - 1 >= y - 1 + 1; // WILL catch this case when it likely shouldn't
```
@mrecachinas mrecachinas changed the title Addresses #1955 Addresses #1955 - Suggests >= y + 1 become > y Sep 17, 2017
@oli-obk
Copy link
Contributor

oli-obk commented Sep 17, 2017

Yay! Thanks for starting this lint.

The detection code is perfect. The actual lint call should use span_lint_and_then and place a span_suggestion with the variable names from the actual code site. For this you'll need to return something more than a Boolean from your detection code though. An Option<String> with the replacement text would be one possibility.

@mrecachinas
Copy link
Author

Sounds good -- I'll make those changes now. Do you think the message should be a bit more specific with respect to adding 1 or subtracting 1, or do you think the general message gets across?

@oli-obk
Copy link
Contributor

oli-obk commented Sep 17, 2017

I think the lint docs are where such details belong. The lint message itself is good

@mrecachinas
Copy link
Author

@oli-obk Sorry for the delay -- check out the latest commit and let me know your thoughts. I can change it to return Option<String> and have the "should I emit a warning" logic handled in the top-most method if you think that would be cleaner.

Copy link
Contributor

@oli-obk oli-obk left a comment

Choose a reason for hiding this comment

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

The approach looks good to me. There's still a lot of code duplication, but that doesn't have to be addressed in this PR.

false
}

fn check_binop(&self, cx: &EarlyContext, block: &Expr, binop: BinOpKind, lhs: &Expr, rhs: &Expr) -> Option<(bool, Option<String>)> {
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm very confused as to how this function successfully compiles ( the return type matches no returned value)

Copy link
Author

Choose a reason for hiding this comment

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

Good catch -- I started moving toward returning the (bool, String) tuple I described above, but I forgot to remove the return value.

I'm not sure why the compiler didn't catch that though. AFAIK there is no implicit None returned.

@oli-obk
Copy link
Contributor

oli-obk commented Sep 24, 2017

You can remove the bool and inner option and just make the entire return type Option<String>

@mrecachinas
Copy link
Author

If you have any other recommendations to reduce the duplicated code, I'm happy to do it in this PR!

Perhaps having the match statements produce the arguments to generate_recommendation and then only call it once?

@oli-obk
Copy link
Contributor

oli-obk commented Sep 24, 2017

I think any further deduplication will only make the code less comprehensible. This looks great now. Let's activate it and see how it goes in the wild :D

@oli-obk oli-obk merged commit 4ab2223 into rust-lang:master Sep 24, 2017
@mrecachinas mrecachinas deleted the feature/int-plus-one branch September 24, 2017 12:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants