Lint unnecessary conversion of OsString or CString to String

[clarfonthey]

For example, something along the lines of:

let files = Vec::new();
for arg in env::args() {
    files.push(File::open(arg));
}

should be suggested as:

let files = Vec::new();
for arg in env::args_os() {
    files.push(File::open(arg));
}

This would also include something like:

let files = Vec::new();
for arg in env::args() {
    files.push(File::open(arg.to_string_lossy()));
}

[HMPerson1]

So it looks like std::env::args/var/vars are the only functions that have _os alternatives.

Unless I'm missing something, there's no easy way to programmatically find these, so this list has to be hard-coded into the lint, so it won't work with other crates that have pairs of functions like this.

[HMPerson1]

Also what exactly constitutes 'unnecessary'? If we define it as 'anywhere where Str(ing) would also typecheck', then that would also catch whenever it's put into a generic data structure, and maybe that would be a false positive since we can't easily know how that data structure is going to be used later?

Or, since File::open/create both take T where T: AsRef<Path>, and both Str(ing) and OsStr(ing) implement that, perhaps we define unnecessary as 'passed as a parameter that is defined as taking T where T: [something] and both Str(ing) and Os/CStr(ing) implement [something]'? But then if that [something] is something like Hash, then that would still catch putting it into a data structure.

Maybe only for traits that are implemented only by Str(ing) and Os/CStr(ing), but that would exclude AsRef<Path> since that's also implemented by std::path::Components.

Or we could avoid this whole mess and just hard-code a list of places where we know for sure that converting to Str(ing) is unnecessary.

I don't know, I'm just thinking out loud.

[HMPerson1]

Actually, I think defining 'unnecessary' as 'passed as a parameter where the return type doesn't change if Os/CStr(ing) were Str(ing) instead' would work well. Though, if there are associated types involved, that would require trait impl lookups, and I'm not sure how expensive that would be.