WIP: New lint: needless_path_new

[ada4a]

fs::read_to_string(Path::new("foo.txt")) -> fs::read_to_string("foo.txt")

The commit history of this might be a bit messy -- it took me some time to figure this lint out. I cleaned it up a bit, but it's still not perfect

Fixes #14668

changelog: [needless_path_new]: new lint

WIP because:

• it was suggested on Zulip to look into using trait obligations for impl AsRef<Path>. Later comments seem to not quite agree? As I said on Zulip, I don't know what these obligations are all about, so let me know if you think I should look into them (I'd appreciate some help as well)
• I know that all the descriptions for this lint are pretty verbose -- I think its purpose is just hard to describe succintly. That would've been easier originally, since I thought the lint would apply only to strings enclosed in Path::new, but that was pretty easy to expand to "any impl AsRef<Path>", so I did that.

[rustbot]

r? @blyxyas

rustbot has assigned @blyxyas.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ada4a]

these two arguments are what makes the CI fail currently, since they are unused. I got them when copy-pasting from mut_reference, and I haven't removed them (yet) because I thought I could use them to give a better warning message. Something like:

format!("the {fn_kind} {name} accepts `AsRef<Path>`, \
and {x} implements that trait, so wrapping it in `Path::new` is unnecessary")

If you think it makes sense to have the message, I'd add it in -- otherwise I'd just remove these arguments

[ada4a]

I have this function signature from mut_reference -- should I maybe replace the dyn with impl here?

[samueltardieu]

I think you need to check that you can use a AsRef<Path>, otherwise you might suggest removing Path::new() while you really need a &Path.

Don't forget to look at the lintcheck logs for your PR. You'll see the first hit is probably wrong, as it requires building a Option<&Path>, not a Option<dyn AsRef<Path>>.

[ada4a]

Don't forget to look at the lintcheck logs for your PR.

oh, didn't know about that! thank you, that's very helpful

I think you need to check that you can use a AsRef<Path>, otherwise you might suggest removing Path::new() while you really need a &Path.

You'll see the first hit [in lintcheck] is probably wrong, as it requires building a Option<&Path>, not a Option<dyn AsRef<Path>>.

I thought I already covered that with the following line:

&& implements_asref_path(*parameter)

I even have a test case for exactly this!

// no warning
fn takes_path(_: &Path) {}
takes_path(Path::new("foo"));

But now that I think about it, the check above doesn't actually work?... It just checks that whatever type parameter has itself implements AsRef<Path>, and that is the case for Path. I wonder why the test even works in that case... Maybe something to do with Path vs &Path?

I guess what I need to check instead is that parameter is impl AsRef<Path>. is_type_diagnostic_item seems to be closest to what I want, but it wouldn't include the impl part? Btw that makes me wonder if I should check for dyn AsRef<Path> as well

[ada4a]

But the weirdest thing is that Some(..) is not even a fucntion/method call?... The lint is supposed to only check expressions that are ExprKind::Call or ExprKind::MethodCall -- but maybe the former actually includes anything of the form foo(bar)?...

EDIT: indeed it does. but I guess this is not actually the root cause of the problem, so we could keep it? Maybe the function/method restriction should not even be necessary, maybe we should just check that the place the expression is in requires an impl AsRef<Path>, be that place a parameter in a function call, or e.g. a RHS of an assignment, like

let _: Option<impl AsRef<Path>>: Some(Path::new("foo.txt"));

(assuming impl Trait in this position would be valid, but this is just an example)