-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 some clippy lints for library/std/src/sys/windows #118154
Conversation
We intentional use the Windows API style here.
This comment has been minimized.
This comment has been minimized.
I was so busy playing with clippy that I forgot fmt. |
0c38f22
to
1cd6dcd
Compare
should definitely get a perf run when you think its ready. |
A perf run is very unlikely to show any changes seeing as this is Windows only. Also I'm not really convinced any of these lints would affect perf. I think the only ones that might potentially (and I'm sceptical) are |
unneeded `return` statement
This is where our Windows API bindings previously (and incorrectly) used `*mut` instead of `*const` pointers. Now that the bindings have been corrected, the mutable references (which auto-convert to `*mut`) are unnecessary and we can use shared references.
the borrowed expression implements the required traits
this expression creates a reference which is immediately dereferenced by the compiler
casting to the same type is unnecessary
calling `subsec_micros()` is more concise than this calculation
unnecessary closure used with `bool::then`
manual implementation of `Option::map`
1cd6dcd
to
0e4f04c
Compare
0e4f04c
to
b9fe367
Compare
if first_code_unit_remaining >= 0xDCEE && first_code_unit_remaining <= 0xDFFF { | ||
if matches!(first_code_unit_remaining, 0xDCEE..=0xDFFF) { |
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 confirmed that using matches!
is exactly equivalent to using a manual if (in terms of codegen) and I do think it's clearer.
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.
Yup, so long as there's only a single range in the matches!
then it's just as good.
(If there's multiple then things get complicated, see #103024 (comment) if you're curious.)
@@ -156,7 +156,7 @@ impl DirEntry { | |||
} | |||
|
|||
pub fn path(&self) -> PathBuf { | |||
self.root.join(&self.file_name()) | |||
self.root.join(self.file_name()) |
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.
Can we uplift this clippy lint? 🙂
(Not in this PR, obviously)
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.
That's needless_borrows_for_generic_args
. There's also the related needless_borrow
which found a lot too!
@@ -36,7 +36,7 @@ impl<'a> IoSlice<'a> { | |||
|
|||
#[inline] | |||
pub fn as_slice(&self) -> &[u8] { | |||
unsafe { slice::from_raw_parts(self.vec.buf as *mut u8, self.vec.len as usize) } |
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.
Hmm, this is PSTR
, which is defined as *mut u8
, so the change is fine, but I wonder if it's "really" *mut u8
vs *mut c_char
, since the latter might want to be signed char, and where this cast would actually do something.
Since it's not using c_char
today, though, it's probably fine, since casts can be added back if it's ever relevant.
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.
That's true. Though we're a bit at the mercy of the win32metadata project here (which is what our bindings are ultimately generated from) which might not necessarily follow what we think a c_char
is (as it has no particular need to follow C).
Fix some clippy lints for library/std/src/sys/windows These issues were shown by running `x clippy` on `library/std` and filtering for `windows/` paths. I think running clippy on the full std would be great but I wanted to start smaller and with something that's hopefully easier to review. It'd be good to eventually run clippy in CI but that's a bigger conversation. I've created separate commits for each clippy lint fixed (with the commit title set to the lint name) and reviewed the changes myself. Most of the fixes here are trivial. r? libs
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
@bors retry that looks spurious "[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled." |
☀️ Test successful - checks-actions |
Finished benchmarking commit (c387f01): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 675.896s -> 674.393s (-0.22%) |
These issues were shown by running
x clippy
onlibrary/std
and filtering forwindows/
paths. I think running clippy on the full std would be great but I wanted to start smaller and with something that's hopefully easier to review. It'd be good to eventually run clippy in CI but that's a bigger conversation.I've created separate commits for each clippy lint fixed (with the commit title set to the lint name) and reviewed the changes myself. Most of the fixes here are trivial.
r? libs