-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
[WIP] Add new lint for xor-ing when pow
was probably intended
#6182
Conversation
r? @ebroto (rust_highfive has picked a reviewer for you, use r? to override) |
The pr should be totally updated, now---everything compiles in the lint itself, but I still can't compile clippy because of master branch problems. |
Looks to be all set now! |
f9e21a1
to
03ca52e
Compare
I'm unsure how to fix the failing test.... it seems like it has something to do with clippy not fixing all of the errors in the uitest, so the |
☔ The latest upstream changes (presumably #6109) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
Minor docs and description changes Co-authored-by: Eduardo Broto <ebroto@tutanota.com>
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a side note, I realized we could improve the lint further, but I think it would be better to leave these improvements for follow-up PRs. I will open the issues after we merge this PR.
- We could give
MachineApplicable
suggestions for the.pow()
case, but would have to handle potential overflows. - We could target
EXPR ^ EXPR
where any of the sides is const-foldable, not only literals. This may require enhancing theconsts
module.
} | ||
} | ||
|
||
fn unwrap_dec_int_literal(cx: &LateContext<'_>, lit: &Lit) -> Option<(u128, LitIntType)> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that we are not using the second element of the returned tuple
enum E { | ||
First = 1 ^ 8, | ||
Second = 2 ^ 8, | ||
Third = 3 ^ 8, | ||
Tenth = 10 ^ 8, | ||
} | ||
|
||
fn main() { | ||
// These should succeed: | ||
let _ = 9 ^ 3; // lhs other than 2 or 10 | ||
let _ = 0x02 ^ 6; // lhs not decimal | ||
let _ = 2 ^ 0x10; // rhs hexadecimal | ||
let _ = 10 ^ 0b0101; // rhs binary | ||
let _ = 2 ^ 0o1; // rhs octal | ||
let _ = 10 ^ -18; // negative rhs | ||
let _ = 2 ^ 0; // zero rhs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can remove the cases that are already tested in the non-fixable file.
{ | ||
let x = 15; | ||
let _ = 10 ^ x; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're missing two tests:
- The RHS is a
const
- The RHS is an immutable binding initialized with a
const
} | ||
} | ||
|
||
fn report_with_ident(cx: &LateContext<'_>, lhs: u128, rhs: &QPath<'_>, span: Span) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In these cases we're not handling the overflow.
let x = 42;
let _ = 2 ^ x;
The suggestion would result in code that does not compile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about this while writing the relevant portions. In order to figure out if this overflows, I'll need to get the literal from the definition (or const or const-binding). Is there a utility for this in clippy
already? Particularly, someone might have something like this:
const A: u32 = 42;
const B: u32 = A;
fn main() {
let c = B;
let _ = 2 ^ c;
}
It seems like I'd need to iterate over the chain of definitions and grab the one that ends in a literal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm not mistaken, there is nothing like this in utils.
I remember doing something similar for the internal lint MATCH_TYPE_ON_DIAGNOSTIC_ITEM
, in the function path_to_matched_type
. I think that could help.
ping from triage @cgm616. There seem to be some fixes left to be done. Do you have any questions on how to proceed here? |
☔ The latest upstream changes (presumably #6333) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
@ebroto 2 weeks have passed with no activity from previous ping, so this should be closed accorging to Rust triage procedure. |
Thanks for the heads-up, Takayuki ❤️ It breaks my heart having to close this as I think it's a cool lint. I will see if I can find some free time to address the last changes myself. |
I know this is closed for triage reasons, but I am going to try to finish this. My school semester is almost done and I've been too busy over the last few weeks, but I should be able to pull this over the finish line soon. |
This is simply a resurrection of #4541, which is inactive. It looks like everything is good to go, pending review.
Closes #4205.
changelog: new lint: [
xor_used_as_pow
]