Add clippy::result_as_ref_deref lint

[aleksanderkrauze]

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]

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

[aleksanderkrauze]

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]

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 correctly¹, 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]

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

[samueltardieu]

nit: could you add error markers (//~^) to lines which are supposed to shown an error? This will then be checked automatically for non-regressions, instead of having to visually inspect changes.

[aleksanderkrauze]

Hi. Sorry for the delay. Can I generate those comments with uibless, or do I have to write them manually? I haven't use them, because I have just copied tests/ui/option_as_ref_deref.rs file and tweaked it, and it already had no such comments.

[Jarcho]

Those would have to be added manually. The tests haven't all been updated to use them, but they are preferred for anything new. You can add //~ lint_name on the end of any line that should lint. e.g.

let _ = res.clone().as_ref().map(Deref::deref).map(str::len) //~ result_as_ref_deref

Using //~^ line_name will let you add it to the following line, but that should only be used for longer lines.

[Jarcho]

Sorry, this one managed to slip past me. I've been not very active for the past month or so (various issues happening at the same time).

A lint can be renamed using cargo dev rename_lint; just make sure to do it as a separate commit. Don't worry about making the change until the FCP (which I will start now) is done just in case anyone has issues with the rename.

Code looks good other than @samueltardieu's comment about error annotations. The version attribute will be fixed when we make the release change log, so it's not the end of the world if it's wrong.

[Jarcho]

It's been a week and looks like a rename to manual_as_deref is good. Command for the rename is cargo dev rename_lint option_as_ref_deref manual_as_deref and should be done as it's own commit.

[bors]

☔ The latest upstream changes (presumably b829d53) made this pull request unmergeable. Please resolve the merge conflicts.