-
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
explicit_counter_loop improvement suggestion #1670
Comments
A further suggestion: self.memory[min..max].copy_from_slice(data) |
Even better, thanks for the suggestion! |
Hello. I would like to try this as my first contribution. But there are three issues:
Should I separate PR? |
The first step would be to address 1. and 2. This should be done in one PR. You have to turn this lint into a You can take a look at
If you have any questions or need help with something, feel free to ask here or open a WIP PR. |
Thank you. I'll make PR for 1. and 2. |
Fix `explicit_counter_loop` suggestion #1670 This code seems to me to work, but I have two question. * Because range expression desugared in hir, `Sugg::hir` doesn't add parenthesis to range expression. Which function is better to check range do you think, `check_for_loop_explicit_counter` or `hir_from_snippet`? * Do you think we need to distinguish between range expression and struct expression that creates `std::ops::Range*`?
This comment has been minimized.
This comment has been minimized.
Never mind. I started to work on a PR that addresses 3. as |
Fix the bugs of `manual_memcpy`, simplify the suggestion and refactor it While I’m working on the long procrastinated work to expand `manual_memcpy`(#1670), I found a few minor bugs and probably unidiomatic or old coding style. There is a brief explanation of changes to the behaviour this PR will make below. And, I have a questoin: do I need to add tests for the first and second fixed bugs? I thought it might be too rare cases to include the tests for those. I added for the last one though. * Bug fix * It negates resulted offsets (`src/dst_offset`) when `offset` is subtraction by 0. This PR will remove any subtraction by 0 as a part of minification. ```rust for i in 0..5 { dst[i - 0] = src[i]; } ``` ```diff warning: it looks like you're manually copying between slices --> src/main.rs:2:14 | LL | for i in 0..5 { - | ^^^^ help: try replacing the loop by: `dst[..-5].clone_from_slice(&src[..5])` + | ^^^^ help: try replacing the loop by: `dst[..5].clone_from_slice(&src[..5])` | ``` * It prints `RangeTo` or `RangeFull` when both of `end` and `offset` are 0, which have different meaning. This PR will print 0. I could reject the cases `end` is 0, but I thought I won’t catch other cases `reverse_range_loop` will trigger, and it’s over to catch every such cases. ```rust for i in 0..0 { dst[i] = src[i]; } ``` ```diff warning: it looks like you're manually copying between slices --> src/main.rs:2:14 | LL | for i in 0..0 { - | ^^^^ help: try replacing the loop by: `dst.clone_from_slice(&src[..])` + | ^^^^ help: try replacing the loop by: `dst[..0].clone_from_slice(&src[..0])` | ``` * it prints four dots when `end` is `None`. This PR will ignore any `for` loops without `end` because a `for` loop that takes `RangeFrom` as its argument and contains indexing without the statements or the expressions that end loops such as `break` will definitely panic, and `manual_memcpy` should ignore the loops with such control flow. ```rust fn manual_copy(src: &[u32], dst: &mut [u32]) { for i in 0.. { dst[i] = src[i]; } } ``` ```diff -warning: it looks like you're manually copying between slices - --> src/main.rs:2:14 - | -LL | for i in 0.. { - | ^^^ help: try replacing the loop by: `dst[....].clone_from_slice(&src[....])` - | ``` * Simplification of the suggestion * It prints 0 when `start` or `end` and `offset` are same (from #3323). This PR will use `RangeTo` changelog: fixed the bugs of `manual_memcpy` and also simplify the suggestion.
Hello! I'm just learning rust and clippy has been a valuable resource for improving my code, thanks!
Today I got confused by one of the clippy suggestions.
I had a look at the source but not sure how to implement proposed improvements.
Consider the following
clippy gives the following warning:
attempting to rework the code as suggested:
... does not compile:
Eventually I realized I just need to wrap the min..max in parenthesis to solve it.
I feel an improved error message in check_for_loop_explicit_counter could look like this:
Also it hardcodes "item" rather than using the variable name "i"
The text was updated successfully, but these errors were encountered: