-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
add Arc to redundant_allocation
#7308
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @phansch (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. |
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.
Hey lengyijun, welcome and thank you for contributing to Clippy.
The new Arc<>
type should also be added to the lint documentation in clippy_lints/src/types/mod.rs
. Maybe you can also make the explanation more general and simply add a bullet point list with all checked types. But that is fully up to you.
Could you also move the change log entry in your PR description to be on the same line as "changelog:" ? Take makes writing it a bit easier in the end.
Edit: For the next time, it would also be good if you pick a better commit message. The "But a function is too long" part seems a bit out of place. It also doesn't link to your GitHub account. I'm not sure if there is any policy for it, but it's always better for tracking changes if the account is linked.
The rest of your changes look good to me 👍
r? @flip1995 I would like to take over this PR review if that works for you 🙃.
0bacc4c
to
ad71930
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.
Thank you for applying the changes so quickly and relinking your GH account in the first commit 👍
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.
The refactoring is fantastic. Thank you, for applying them so quickly. This is just a small change I overlooked last time and a question on something I'm unsure about. 🙃
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.
These are the last changes at a quick glance, I'll do a final review when the applicability has been updated. Thank you for applying all the requested changes 🙃
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 version looks excellent to me 🙃 . @flip1995 could you double-check my review?
I think it would be good if the review commits and implementation commits would be squashed in this case, as there are several commits addressing review changes. However, I would leave that decision up to @flip1995, as I'm not totally sure on this yet 😅.
BTW. I also checked with cargo lintcheck
and it doesn't report any new lint triggers or ICEs, so that is good as well IMO
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 also doesn't link to your GitHub account
That doesn't really matter
I think it would be good if the review commits and implementation commits would be squashed
Yes, squashing some commits together would definitely be good.
I have 2 more things:
- This lint still suggests to change public API. So it should only trigger iff the
avoid_breaking_public_api
is set tofalse
, like discussed here: add Arc toredundant_allocation
#7308 (comment) - We can't really tell what type the programmer actually wanted. For example
Rc<Arc<T>>
: We don't really know if the atomic ref counting provided byArc
is important. ForArc/Rc/Box<&T>
this doesn't matter and suggesting&T
is fine. But if more complex types likeArc
,Rc
andBox
are involved and put together this matters. Right now, always the outer type is suggested as the replacement. I don't think this is a good suggestion. What I would do is to add 2 suggestions to the lint: One that suggests the inner type and one that suggests the outer type as the replacement. But keep in mind that we can't userun-rustfix
tests with two suggestions and the test file has to be split up into the simple caseArc/Rc/Box<&T> -> &T
and the other cases.
(I'm only 90% sure that my concern in 2. is valid. So tell me if I'm wrong here)
I think that this will require some changes to the type module in general and that other type lints (which also affect the public API, like |
Yes, that should also be fine 👍 |
Should we auto fix |
Yes, those should be fine. |
c23c274
to
cf15c7a
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.
LGTM
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.
Impl looks really good now. The error message still could be slightly improved. Remember that you will have to run cargo dev bless
after applying my suggested changes.
"`{}<T>` is already on the heap, `{}<{}<T>>` makes an extra allocation", | ||
inner_sym, outer_sym, inner_sym, |
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 could be improved by also using the result of let generic_snippet = snippet_with_applicability(cx, inner_span, "..", &mut applicability)
here instead of just a generic T
. You can do this nicely with format args:
"`{}<T>` is already on the heap, `{}<{}<T>>` makes an extra allocation", | |
inner_sym, outer_sym, inner_sym, | |
"`{inner}<{generic}>` is already on the heap, `{outer}<{inner}<{generic}>>` makes an extra allocation", | |
inner=inner_sym, outer=outer_sym, generic=generic_snippet |
&format!("usage of `{}<{}<T>>`", outer_sym, inner_sym), | ||
|diag| { | ||
diag.note(&format!( | ||
"`{}<T>` is already on the heap, `{}<{}<T>>` makes an extra allocation", |
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.
Same here (and below): use the snippet of the generic arg instead of a generic type param.
cf15c7a
to
b6aa612
Compare
Thanks, LGTM now! Sorry for the long time without a response, GitHub sometimes doesn't give notifications on force pushes. Can you squash your commits and ping me afterwards, so we can merge this? |
Do I need to squash all commits to one commit? |
Not necessarily. The remaining commits should make sense to keep as separate commits though. E.g. one commit for adding tests, one commit for adding the visitor and one for the actual fix. But you can also just squash everything in one commit. |
b6aa612
to
e575610
Compare
Thx. |
@bors r=xFrednet,flip1995 Thanks! |
📌 Commit e575610 has been approved by |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
…, r=camsteffen Use `avoid-breaking-exported-api` configuration in types module This PR empowers our lovely `avoid-breaking-exported-api` configuration value to also influence the emission of lints inside the `types` module. (That's pretty much it, not really a change worthy of writing a fairy tale about. Don't get me wrong, I would love to write a short one, but I sadly need to study now). --- Closes: #7489 changelog: The `avoid-breaking-exported-api` configuration now also works for [`box_vec`], [`redundant_allocation`], [`rc_buffer`], [`vec_box`], [`option_option`], [`linkedlist`], [`rc_mutex`] changelog: [`rc_mutex`]: update the lint message to comply with the normal format --- r? `@camsteffen,` as you implemented the configuration value cc: `@flip1995,` as we've discussed this change in #7308
fixes #7303
changelog: add Arc to
redundant_allocation