Add lint for unnecessary lifetime bounded &str return

[GnomedDev]

Closes #305.

Currently implemented with a pretty strong limitation that it can only see the most basic implicit return, but this should be fixable by something with more time and brain energy than me. Cavets from #13388 apply, as I have not had a review on my clippy lints yet so am pretty new to this.

changelog: [`unnecessary_literal_bound`]:  Add lint for unnecessary lifetime bounded &str return. 

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @xFrednet (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

[Centri3]

I think maybe tcx.named_bound_var should work for this? I'm not sure whether this would be before inference or not, but if it is a Ty should give you all the info you need to generalize this to work outside of just &str. Regions are erased in the typeck results, however tcx.fn_sig() should still work.

Unfortunately, I don't think there would be any way to know if it's inferred nor can you get the span of a Ty easily. Might be annoying. My first idea to get around that is to recurse over both the HIR Ty and Ty at once but that seems incredibly finicky; however, the solution should be regions regardless of how it's implemented.

[GnomedDev]

I don't know how I would use named_bound_var and it seems out of scope for the idea/issue this is closing. I feel like this is letting perfect be the enemy of good, as a followup PR can generalize or improve this lint however it wants.

[Centri3]

Well, at the end of the day regions are practically lowered lifetimes (and scopes). It's not at all out of scope when the original issue cannot reliably be solved & generalized by parsing the source code alone, and by tracking lifetimes you're doing exactly what the compiler grants to you in such queries.

[Centri3]

Also now that I think about it, this could apply to b"thing" and c"thing" as well

[GnomedDev]

Okay, I'll look into using named_bound_var and if I can't figure it out close this PR as it doesn't sound wanted with this implementation.

[Centri3]

Note, I'd definitely be fine with it being added if it's done this way, but it'll be harder to update + it'd be easier to rewrite it anyway

named_bound_var when used on TyKind::Ref's containing type's id practically just returns a Region, there's better documentation on the RegionKind

[GnomedDev]

I have tried both

dbg!(cx.tcx.named_bound_var(ret_hir_ty.hir_id));

and

dbg!(cx.tcx.named_bound_var(inner_hir_ty.hir_id));

and they both always return none by the time we get past the "is str" check.

[xFrednet]

@Centri3 since you already looked at this, do you want to take over the review?

[Centri3]

I have tried both

dbg!(cx.tcx.named_bound_var(ret_hir_ty.hir_id));

and

dbg!(cx.tcx.named_bound_var(inner_hir_ty.hir_id));

and they both always return none by the time we get past the "is str" check.

In specific I'm fairly sure you'll need the HirId of the LifeTime contained in ret_hir_ty.kind

[Centri3]

r? Centri3

[Centri3]

Unfortunately looking closely at the implementation of it I don't know if named_bound_var will work. Maybe the fn_sig can be done, but probably not for now. I'll look for some way to deal with stuff like Result<(), &str>

[GnomedDev]

How about we land this, then if you want you can improve it via lifetime stuff? As is, this doesn't add any false positives (to my knowledge) and is simply a little limited in what it lints (which is better than the not linting at all currently)

[bors]

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

[GnomedDev]

Hey, @Centri3, just double checking you saw the comment above? Nearly been a month.

[Centri3]

I don't have the time at the moment unfortunately. I'll reroll
r? rust-lang/clippy

[bors]

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

[Manishearth]

@bors r+

[bors]

📌 Commit b62d262 has been approved by Manishearth

It is now in the queue for this repository.

[bors]

⌛ Testing commit b62d262 with merge f328623...

[bors]

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: Manishearth
Pushing f328623 to master...