Skip to content
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 clippy::result_as_ref_deref lint #13474

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

aleksanderkrauze
Copy link

changelog: added new lint result_as_ref_deref

closes #13342

I've added new lint result_as_ref_deref, which mirrors already existing lint option_as_ref_deref and reused its existing check function.

Open question is should this be another lint, or should two of them be merged together? I've asked about it in the original issue (proposing manual_as_ref_deref name), and @Jarcho suggested the same thing (and proposed manual_fallible_as_deref name).

I'm not sure what is clippy's policy regarding renaming lint names, so I opted into just adding new lint and waiting for the review.

@rustbot
Copy link
Collaborator

rustbot commented Sep 28, 2024

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Jarcho (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Sep 28, 2024
@aleksanderkrauze
Copy link
Author

aleksanderkrauze commented Sep 29, 2024

Uh. I think I messed something up. I've pulled master branch to be up to date, rebased my working branch on top of it, and now tests don't pass and a whole bunch of code needs to be reformatted. However when I look at the diff between my branch and upstream/master I only see my changes. Help would be appreciated. 😃

EDIT. After some more rebasing and tweaking all seams to work now. I don't know what I did previously wrong, but now CI passes.

@aleksanderkrauze aleksanderkrauze force-pushed the add_result_as_ref_deref_lint branch 2 times, most recently from 1b386e5 to 0349ca7 Compare September 29, 2024 11:28
@aleksanderkrauze
Copy link
Author

I was browsing the standard library, and have found one more "similar" pattern. std::pin::Pin has an unstable method as_deref_mut, which goes from Pin<&mut Pin<Ptr>> to Pin<&mut <Ptr as Deref>::Target> and under the hood it calls unsafe { self.get_unchecked_mut() }.as_mut(). Notably this method is a safe wrapper around another unsafe method from the std. I thought that it would be nice if clippy could also suggest using this method, instead of re-implementing it.

One problem though is that this method is unstable. I've read its tracking issue and if I understand correctly1, its FCP has just finished, so it should be stable pretty soon. If such lint were to be added, would it have to wait until pin_deref_mut feature was stabilized, or are there lints that only trigger when one is using a nightly compiler version?

Do you think it would be good to add such a lint? Sorry for writing about it in this PR. I thought it would be better to ask about it here, because it loosely relates to lints that I am working on here. If you believe that this discussion should be moved to separate issue, please tell me so.

One way that this would relate to lints that I worked on in this PR is naming. There is already open question in this PR about naming of lints that check for [Option/Result].as_ref().map(Deref::deref), whether there should be two separate lints option_as_ref_deref and result_as_ref_deref, or one named manual_as_ref_deref (or similarly). If you would want to accept adding lint that suggests using Pin::as_deref_mut, then it would be better to consider naming implications now.

I thing that this is pretty obvious that it should be a separate lint, and not joined with [option|result|manual]_as_ref_deref. But if we merged option_as_ref_deref with result_as_ref_deref into one, then wouldn't it be confusing to have manual_as_ref_deref/manual_as_deref and pin_manual_as_deref_mut/pin_as_deref_mut? Maybe it would be better then to leave Option's and Result's _as_ref_deref lints separate. I might be looking into this too hard perhaps. Please let me know what you think about all of this.

Footnotes

  1. I am quite new to rust-lang development process, so I might be making wrong assumptions here. Please let me know in such case.

@aleksanderkrauze
Copy link
Author

I haven't heard back from my assigned reviewer for last 2 weeks, so I took liberty to re-roll reviewer using a fair dice. I hope you won't mind it. 😃

r? @Alexendoo

@rustbot rustbot assigned Alexendoo and unassigned Jarcho Oct 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add result_as_ref_deref lint
5 participants