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
Fix clippy warnings #2108
Fix clippy warnings #2108
Conversation
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.
Related: #2076.
Quick notes: Agree with most of these, maybe we should enable clippy
in CI in the future?
However, I think we should discuss the match
changes in the examples: I think there's value in keeping them as-is, because it provides a nice "template" that users can easily copy-paste and extend on. Same goes for winit
developers, I think it's useful to be able to easily drop in an extra pattern when debugging an example.
I think the match changes make sense but happy to roll them back to keep this PR easy to merge.
? |
Honestly, can I choose both? At first glance I meant only the |
c4029b2
to
0be7961
Compare
yep, both was definitely an option! |
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.
Looked through it all, it looks fine, nice work!
Would it be possible for you to do the same for the other platforms as well?
src/lib.rs
Outdated
@@ -131,6 +131,7 @@ | |||
|
|||
#![deny(rust_2018_idioms)] | |||
#![deny(rustdoc::broken_intra_doc_links)] | |||
#![allow(clippy::new_without_default)] |
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 think it would be fine to have Default
impls where it makes sense, at least on public types, but this can be deferred to another PR if it's an issue.
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.
Alright, reverted this so each individual case can be investigated.
@@ -27,7 +27,7 @@ impl Icon { | |||
data.push(rgba_icon.height as Cardinal); | |||
let pixels = rgba_icon.rgba.as_ptr() as *const Pixel; | |||
for pixel_index in 0..pixel_count { | |||
let pixel = unsafe { &*pixels.offset(pixel_index as isize) }; | |||
let pixel = unsafe { &*pixels.add(pixel_index) }; |
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.
This one scared me for a second (thought it was suddenly trying to use integer addition, which is strictly not the same as pointer offset), but pointer::add
is just a convenience for this exact case
0be7961
to
3d5e8a8
Compare
I do actually have access to macos and windows so im happy to do those as well, but lets land this PR first. |
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.
Thx for the PR. It would be nice to finally resolve this issue #1402.
To test platforms other than your host I could recommend you doing something like cargo +nightly clippy --target=x86_64-pc-windows-msvc --all-targets
(this works for like every platform winit supports).
If you are happy with the fixes in this PR please land them first. |
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.
looks mostly ok to me
e0484d8
to
5aeef57
Compare
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 like this should be ready to be merged.
I'm assuming adding clippy to our CI config is intended to be added in a separate PR.
cargo fmt
has been run on this branchcargo doc
builds successfullyCHANGELOG.md
if knowledge of this change could be valuable to usersThere are still some lints left, but this should be all the non-controversial ones. The rest can be ignored or fixed in a separate PR.
I decided to just ignore new_without_default as it seems really aggressive to me. Happy to just remove the ignore and leave the decision for a follow up PR.
Make sure to review the diff with whitespace disabled to keep the match changes readable.