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

Suggest longer lifetimes for function return values #1304

Closed
matthew-piziak opened this issue Oct 28, 2016 · 3 comments
Closed

Suggest longer lifetimes for function return values #1304

matthew-piziak opened this issue Oct 28, 2016 · 3 comments
Labels
A-lint Area: New lints C-an-interesting-project Category: Interesting projects, that usually are more involved design/code wise. E-hard Call for participation: This a hard problem and requires more experience or effort to work on

Comments

@matthew-piziak
Copy link

In utkarshkukreti/select.rs@ae590b5, the returned references are given a type-bound lifetime.

It would be nice if clippy could make these recommendations automatically.

@Manishearth Manishearth added E-hard Call for participation: This a hard problem and requires more experience or effort to work on A-lint Area: New lints C-an-interesting-project Category: Interesting projects, that usually are more involved design/code wise. labels Oct 28, 2016
@Manishearth
Copy link
Member

This would be interesting to implement; you have to track where the borrow comes from.

@matthew-piziak
Copy link
Author

@oli-obk and I talked about this during Rust Belt Rust. We tried to refactor a piece of code to the effect of replacing a &String parameter to a &str parameter. We eventually tracked down to a lifetime problem in the select.rs library. When we went to make a pull request we discovered that the change had already been made in master.

@camsteffen
Copy link
Contributor

camsteffen commented Dec 16, 2020

Same as #305

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: New lints C-an-interesting-project Category: Interesting projects, that usually are more involved design/code wise. E-hard Call for participation: This a hard problem and requires more experience or effort to work on
Projects
None yet
Development

No branches or pull requests

3 participants