-
Notifications
You must be signed in to change notification settings - Fork 1.7k
WIP: New lint: needless_path_new
#14895
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
base: master
Are you sure you want to change the base?
Conversation
recommended on Zulip
we call `implements_asref_path` twice on each iteration of the loop, so all the repeated creation could get expensive
name: &str, | ||
fn_kind: &str, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
it was recommended on Zulip to keep the check, so do that and give the motivation for having it
apparently a common thing to do? definitely reduces verbosity
taken care of by `Ty::new_adt`
|
||
fn check_arguments<'tcx>( | ||
cx: &LateContext<'tcx>, | ||
arguments: &mut dyn Iterator<Item = &'tcx Expr<'tcx>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have this function signature from mut_reference
-- should I maybe replace the dyn
with impl
here?
as advised on Zulip
I think you need to check that you can use a 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 |
oh, didn't know about that! thank you, that's very helpful
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 I guess what I need to check instead is that |
But the weirdest thing is that 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 let _: Option<impl AsRef<Path>>: Some(Path::new("foo.txt")); (assuming |
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 lintWIP because:
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)Path::new
, but that was pretty easy to expand to "anyimpl AsRef<Path>
", so I did that.