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

Warn when using to_owned on already owned types #6715

Closed
kangalio opened this issue Feb 10, 2021 · 6 comments · Fixed by #6730
Closed

Warn when using to_owned on already owned types #6715

kangalio opened this issue Feb 10, 2021 · 6 comments · Fixed by #6730
Assignees
Labels
A-lint Area: New lints good-first-issue These issues are a good way to get started with Clippy T-middle Type: Probably requires verifiying types

Comments

@kangalio
Copy link

kangalio commented Feb 10, 2021

What it does

By virtue of deferencing to &[T], Vec implements several methods such as .to_owned() or .to_vec(). When called on Vec, these methods do the same thing as .clone(), all the while being more confusing ("why call to_owned or to_vec on something that already is a Vec and is owned?")

Categories

  • Kind: style

What is the advantage of the recommended code over the original code

As mentioned above, to_vec and to_owned are potentially misleading and confusing when used on Vec. clone is a clearer alternative.

Drawbacks

None.

Example

let a = vec![1, 2, 3];
let b = a.to_vec();

Could be written as:

let a = vec![1, 2, 3];
let b = a.clone();

Additional comments

Same applies to String with .to_owned() and .to_string(). Or PathBuf with .to_owned() and to_path_buf(). Or I suppose CString with .to_owned(). There's a lot of these cases in the standard library actually. Should those cases be handled using the same lint?

@camsteffen camsteffen added A-lint Area: New lints good-first-issue These issues are a good way to get started with Clippy T-middle Type: Probably requires verifiying types labels Feb 10, 2021
@camsteffen
Copy link
Contributor

Good idea.

There's a lot of these cases in the standard library actually. Should those cases be handled using the same lint?

Yes 👍 We can call the lint owned_to_owned.

@kangalio kangalio changed the title Warn when using to_owned to clone Vec's Warn when using to_owned on already owned types Feb 10, 2021
@anall
Copy link
Contributor

anall commented Feb 12, 2021

@rustbot claim

I think I've got something mostly working for this, but I am not sure if I am doing anything the proper way, or if there is a better way to go about this.

I have a few hangups with the "Additional Comments" -- and I still need to figure out how to handle PathBuf or ArbitraryCustomType for that (and how to convert those to snake case path_buf and arbitrary_custom_type)

@camsteffen
Copy link
Contributor

@anall Feel free to ask questions on Zulip or open a work in progress PR.

Converting to snake case is not the right approach. Instead there should be a list of known "to owned" functions that are equivalent to clone. It is okay if the lint only covers one type like Vec at first.

@anall
Copy link
Contributor

anall commented Feb 15, 2021

Re the "Additional comments", as far as I can tell with a really rough heuristic-filtered grep, these are the types in the standard library that have a "to_type" method (ignoring Owned which trips my heuristic given how the trait is set up):

  • OsString
  • PathBuf
  • String (to_string is already handled by string_to_string, but could be moved to be handled here)
  • Vec

@camsteffen
Copy link
Contributor

I like the idea of replacing string_to_string. Seems like the exact same concept. @flip1995 do you agree? Incidentally it would be upgraded to style.

@flip1995
Copy link
Member

I would just keep string_to_string, since it is a restriction lint. I wouldn't make this lint warn-by-default, because calling to_owned instead of clone doesn't really make a difference. And if the clone is unnecessary, redundant_clone should pick it up.

@bors bors closed this as completed in 7154b23 Feb 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: New lints good-first-issue These issues are a good way to get started with Clippy T-middle Type: Probably requires verifiying types
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants