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

Clear Clippy warnings #35

Closed
wants to merge 15 commits into from
Closed

Clear Clippy warnings #35

wants to merge 15 commits into from

Conversation

tcharding
Copy link

@tcharding tcharding commented Feb 10, 2021

This PR clears all Clippy warnings (incl. nightly) except for documentation of unsafe

warning: unsafe function's docs miss `# Safety` section

Please note, the first patch runs cargo fmt if that is not wanted I can remove it.

Commit d7f6956 Use std::mem::MaybeUninit needs special attention please.

This is kinda a big PR for my first one so if you'd like me to split the more trivial patches out into a separate PR I can do that also.

Thanks

@@ -70,17 +71,9 @@ impl Mpq {
&mut self.mpq
}

pub fn new() -> Mpq {
Copy link

Choose a reason for hiding this comment

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

We can’t go around deleting parts of the public API just because Clippy suggests it…

Copy link
Author

Choose a reason for hiding this comment

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

Oh, very good point. My bad.

Copy link
Author

Choose a reason for hiding this comment

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

Will fix and re-spin tomorrow. Thanks for looking at this.

@tcharding tcharding changed the title Clear cippy warnings Clear Clippy warnings Feb 10, 2021
@andersk
Copy link

andersk commented Feb 10, 2021

You claim that the first commit is cargo fmt, but in reality it only reformats three files, with four other files getting reformatted in various other commits. This makes it difficult to see what those commits actually changed.

@tcharding
Copy link
Author

You claim that the first commit is cargo fmt, but in reality it only reformats three files, with four other files getting reformatted in various other commits. This makes it difficult to see what those commits actually changed.

Oh boy, sloppy PR huh. I moved that commit to the front of the list and didn't look through the first three diffs, my bad (again). Feel free to ignore me for the rest of the day, I'll make a better effort tomorrow.

@tcharding
Copy link
Author

Implemented review suggestions:

  • Fixed all cargo fmt changes to be in the first patch.
  • Removed default -> new change

Question, I'm not totally sure the Error change is not a breaking API change. I think it is but am not sure. Please review 43cee7b Implement Display for error types with this in mind.

Thanks.

@andersk
Copy link

andersk commented Feb 11, 2021

  • Fixed all cargo fmt changes to be in the first patch.

Despite your claim, this is not fixed.

}
}

impl Error for ParseMpqError {
Copy link

Choose a reason for hiding this comment

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

You have removed these impls completely, which is neither desirable nor backwards-compatible. The soft-deprecation of Error::description means you can use an empty impl, not no impl.

Copy link
Author

Choose a reason for hiding this comment

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

Oh cool, thanks for the info. I will fix and re-spin.

@tcharding
Copy link
Author

  • Fixed all cargo fmt changes to be in the first patch.

Despite your claim, this is not fixed.

Woah, bad vodoo on this PR. I was sure I went through the whole patch set but seems I don't know how to read a diff.

Clippy emits:

  warning: trait objects without an explicit `dyn` are deprecated

Use dyn as suggested.
Clippy emits:

  warning: redundant field names in struct initialization

As suggested, remove the redundant field names.
`unititialized` is deprecated. Use the newer `MaybeUninit`.
Error trait has changed a bit since Rust v1.30.0 we can implement
`Display` and remove the deprecated `description`. Also `cause` has a
default implementation that returns `None` so removing the custom one
makes no logic change.
Clippy emits:

  warning: manual `RangeInclusive::contains` implementation

As suggested, we can use a range and `.contains`.
We have a few places where we manually switch on conditionals, we can
use `std::cmp` for this.

Found by Clippy.
@tcharding
Copy link
Author

tcharding commented Feb 12, 2021

3rd time lucky. This time I've actually put all the fmt changes in the first patch. Also split out a separate patch for the popcount unit test fix aa23b5d Assert in popcount test (found by @mikelodder7 in his PR). Finally I added back in the empty 'impl Error' blocks as required.

Thanks for your patience.

@mikelodder7
Copy link

Awesome

src/mpz.rs Outdated
Comment on lines 193 to 199
let mut first_nul = None;
let mut index : usize = 0;
for elem in &vector {
for (index, elem) in vector.iter().enumerate() {
if *elem == 0 {
first_nul = Some(index);
break;
}
index += 1;
}
Copy link

Choose a reason for hiding this comment

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

Could be simplified to

let first_nul = vector.iter().position(|elem| *elem == 0);

Copy link
Author

Choose a reason for hiding this comment

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

Added the .unwrap_or onto it as well :)

src/test.rs Outdated
}

#[test]
fn test_to_str_radix() {
let x: Mpz = From::<i64>::from(255);
assert!(x.to_str_radix(16) == "ff".to_string());
assert!(x.to_str_radix(16) == *"ff");
Copy link

Choose a reason for hiding this comment

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

The * isn’t needed; simply assert!(x.to_str_radix(16) == "ff") works fine (or assert_eq!).

Copy link
Author

Choose a reason for hiding this comment

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

Cool, this surprised me, I didn't think assert_eq! could compare an &str with a String. Thanks, implemented as suggested. I added it as a new patch on top of this branch to make re-review easier. I can squash it with the original one if you prefer.

Copy link

Choose a reason for hiding this comment

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

Rust has a boatload of PartialEq impls, including PartialEq<str> for str, PartialEq<String> for String, PartialEq<str> for String, PartialEq<String> for str, PartialEq<&'a str> for String, PartialEq<String> for &'a str.

You haven’t actually pushed anything though. I’m not the maintainer, but for my part I’m fine with squashing.

Copy link
Author

Choose a reason for hiding this comment

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

Squashed and force pushed. Thanks for the tip about PartialEq implementations!

Instead of manually iterating for the first nul character we can use the
`position` combinator. This reduces lines of code considerably.
The only reason we have the function return and match statement is to
give meaning to the TODO. Clippy does not like this code, suggests use
of `matches!` macro. Instead, we can explain the TODO more fully in text
and remove the code.
Clippy emits:

  warning: `0 as *mut _` detected

As suggested, use `std::ptr::null_mut::<size_t>()` instead.
Clippy emits:

  warning: unneeded `return` statement

As suggested, do not use explicit return statement.
Clippy complains a bunch about various things like

  warning: statement can be reduced

This is caused by unusual code in unit tests because we are
intentionally testing the operator implementations.

These warnings can be cleared by ignoring the return value.
The current test of `popcount` is not doing anything. Add an assertion
on the expected return value.
We can take advantage of Rust's `PartialEq<str> for String`
implementation when doing test assertions.
We are testing the operator implementation, instruct Clippy to ignore
the `eq_op` lint.
@tcharding
Copy link
Author

Any progress on this one please? I wouldn't normally ask but quite a bit of effort was supplied by @andersk during review it would be nice to see this one go in.

@tcharding
Copy link
Author

tcharding commented Jan 19, 2022

This has been open for almost a year now, closing.

@tcharding tcharding closed this Jan 19, 2022
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.

None yet

3 participants