`ptr_arg` should trigger for `Option<&PathBuf>`

[BenjaminBrienen]

Summary

A parameter of type Option<&PathBuf> could instead of of type Option<&Path>.

Lint Name

ptr_arg

Reproducer

I tried this code:

fn foo(maybe_path: Option<&PathBuf>) {
    if let Some(path) = maybe_path {
        File::create(path).unwrap();
    }
}

I expected to see this happen:

ptr_arg triggers

Instead, this happened:

It doesn't

Version

rustc 1.89.0 (29483883e 2025-08-04)
binary: rustc
commit-hash: 29483883eed69d5fb4db01964cdf2af4d86e9cb2
commit-date: 2025-08-04
host: x86_64-unknown-linux-gnu
release: 1.89.0
LLVM version: 20.1.7

[ada4a]

This doesn't seem to have anything to do with the Option -- if I remove it, I still get no lint:

fn foo(path: &PathBuf) {
    File::create(path).unwrap();
}

It seems like File::open is the actual culprit here: the type of its argument is impl AsRef<Path>, and I think the lint is not smart enough to realize that &Path could be used for that just as well? Because if I change it to a method on PathBuf implemented through Deref<Target=Path>, the lint fires again:

fn foo(path: &PathBuf) {
    let _ = path.as_os_str();
}

But you're right as well: if we go full circle, even that doesn't work when we reintroduce the Option:

fn foo(maybe_path: Option<&PathBuf>) {
    if let Some(path) = maybe_path { 
        let _ = path.as_os_str();
    }
}

So I guess this issue should really be split in two.

[BenjaminBrienen]

Oh, I used that method as a contrived example. I replaced PathBuf with Path in my code and it worked.

[ada4a]

it worked

You mean the code compiled after the change? If so, then of course, the change is valid, it's just that the lint doesn't suggest it.. Or maybe I'm misunderstanding you?

[BenjaminBrienen]

Looks like the "real world example" is the same issue with AsRef<Path>. See test-utils/src/lib.rs try_ensure_file_contents. It doesn't trigger a lint if you change it to file: &PathBuf.

file is only used as file: impl AsRef<Path> and &*file in that method.

[ada4a]

You mean this? That was a bit of a search, please just give a link next time 😅

But yeah, it's most likely the std::fs::read_to_string here that trips up the lint

[BenjaminBrienen]

This gives no lints:

pub fn foo(bar: &PathBuf, bazzy: Option<&PathBuf>) {
    let _ = bar;
    let _ = bazzy;
}

This only gives a lint for the first argument:

pub fn foo(bar: &PathBuf, bazzy: Option<&PathBuf>) {
    let z = bar;
    let zz = bazzy;
}

I expect that both arguments trigger the lint.

[zihan0822]

Not really sure whether we should introduce this. We did not lint Option<&Vec<_>>, Option<&String> etc as well, not just Option<&PathBuf>.

[ada4a]

Fwiw I think those would be good suggestions as well -- but getting the additional logic right will definitely be a challenge

[ada4a]

@BenjaminBrienen the underscore thing is intentional -- it was added in #15105 to avoid churn during rapid prototyping

EDIT: though in that case I'm not sure why this code (from an earlier example) does lint:

fn foo(path: &PathBuf) {
    let _ = path.as_os_str();
}

EDIT 2: I think I know now: in the lint, we look, for each parameter, for the first place in the body of the function that kind of concreticizes the type of the parameter. In the case like this:

fn foo(p: &PathBuf) {
    let _ = p;
}

it's, unsurprisingly, the let stmt. And in the case of those, we check if the binding's name starts with a _, in which case we don't bother linting, to avoid churn.

But in the example before, that first-use place is actually the method call path.as_os_str(), and so we don't do the _ check, and so still lint. I'd say that's pretty reasonable, since we are using the binding in some way