-
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
size_of_in_element_count: Disable lint on division by byte-size #6578
size_of_in_element_count: Disable lint on division by byte-size #6578
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @flip1995 (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
@nico-abram Is there by chance a test you'd be fine to remove? I guess it should be fine to test all affected functions just once to make sure they trigger, then test all the expression variants on just one function (ie. no need to test |
I think most of the tests left are testing different functions/methods. Maybe you can combine some of the element count expression tests with tests for specific functions? Like removing If possible IMO keeping each case as cleanly separated as possible is best but I'm not a maintainer. Whoever reviews this can probably give you better feedback |
@nico-abram Correct, in hindsight the top half tests various functions (ie. none has been accidentally skipped from the linting code), the bottom half tests all expressions. There was only one overlapping thing with I guess the only recommended solution beyond that is to split the test out in two parts (one for function inclusion, the other for variation in the expressions), but that doesn't seem necessary in this MR at least (unless one wishes to re-add the test for |
On another side, do you think it's relevant to also fix #6590 here? |
@ThibsG That looks like exactly the mistake this lint is protecting against. The function described there takes a single Otherwise, matching types left and right is a completely different issue (and iirc why this lint doesn't trigger when the type on the left and right is different). |
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.
Changes LGTM
There was only one overlapping thing with copy() which has been removed to get back below 200 lines.
This restriction in Clippy is there to keep tests to a maintainable size. Please don't remove tests because of this. Your suggestion of splitting up the tests sounds reasonable to me. Please do this in a separate commit. You can create a directory for tests for this lint or just append the test file with _{function,expression}
or similar.
2c6c0a1
to
33c8bc2
Compare
@flip1995 Thanks for confirming, the tests are now split up in two files distinguishing function "completeness" and expression variants, obviously in separate commits 😉 If I understand the docs correctly, I should now (be able to) do this: @rustbot label -S-waiting-on-author +S-waiting-on-review Right? |
…ions An upcoming test case for new expresssion variants make the stderr file go over 200 lines. Split this test case in two to have a clear distinction between checking whether the lint is still applying on all the functions with member counts as argument, versus validating various member-count expressions that may or may not be invalid.
It is fairly common to divide some length in bytes by the byte-size of a single element before creating a `from_raw_parts` slice or similar operation. This lint would erroneously disallow such expressions. Just in case, instead of simply disabling this lint in the RHS of a division, keep track of the inversion and enable it again on recursive division.
33c8bc2
to
d4bf59b
Compare
@bors r+ Thanks! Great job! |
📌 Commit d4bf59b has been approved by |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
Fixes #6511
It is fairly common to divide some length in bytes by the byte-size of a single element before creating a
from_raw_parts
slice or similar operation. This lint would erroneously disallow such expressions.Just in case, instead of simply disabling this lint in the RHS of a division, keep track of the inversion and enable it again on recursive division.
changelog: Do not trigger size_of_in_element_count when dividing by element size