extend `clippy_utils::path_to_local()` to handle Cast expressions

[benacq]

Description

clippy_utils::path_to_local() currently accepts a Path expression and returns the canonical HirId of the local, example below:

let x: u32 = 40;

The Path expression for the variable x inside the Let statement will resolve correctly, however the variable b in the example below returns None when passed to the function, because the Path expression is wrapped inside a Cast expression.

let a: i32 = 10;

let b = a as u32;

Version

rustc 1.87.0-nightly (00f245915 2025-02-26)
binary: rustc
commit-hash: 00f245915b0c7839d42c26f9628220c4f1b93bf6
commit-date: 2025-02-26
host: aarch64-apple-darwin
release: 1.87.0-nightly
LLVM version: 20.1.0

[samueltardieu]

I am not sure I understand what you are requesting. Would you want to pass the Expr corresponding to a as u32 to path_to_local() and have it return the canonical HirId of a even though the Expr is not a path to a local binding?

Can you explain why you would need to do this? I wonder if we are in presence of a XY problem here.

[benacq]

I am not sure I understand what you are requesting. Would you want to pass the Expr corresponding to a as u32 to path_to_local() and have it return the canonical HirId of a even though the Expr is not a path to a local binding?

Can you explain why you would need to do this? I wonder if we are in presence of a XY problem here.

Apologies for the miscommunication or confusion, but yes that is what i seek to achieve, perhaps path_to_local() may not be the appropriate function to refactor to achieve that, or there is an existing utility function for that.

in my is_referencing_same_variable function here, i have some boilerplate code handling casted types, and looking the implementation of path_to_local, i thought handling casted types would be cool to get rid of most of the boilerplate that may come with doing similar checks.

example implementation below:

fn some_new_utility_function_name(expr: &Expr<'_>){
     if let ExprKind::Cast(path, _) = &expr1.kind {
          return path_to_local(path)
    }

  None
}

i am assuming a new function here because i understand your point about passing an expression that is not a path to path_to_local.

does this make any sense?

[samueltardieu]

example implementation below:

fn some_new_utility_function_name(expr: &Expr<'_>){
if let ExprKind::Cast(path, _) = &expr1.kind {
return path_to_local(path)
}

None
}

i am assuming a new function here because i understand your point about passing an expression that is not a path to path_to_local.

does this make any sense?

I wonder if you're not looking for path_to_local(peel_casts(expr)), where peel_casts() is currently defined in clippy_lints/src/transmute/transmute_null_to_fn.rs.

But I am not sure you need to detect casts to implement the manual_checked_sub lint you are working on, at least for the basic expr1 - expr2 case where expressions are side-effect-free and not both of them are constants.

[benacq]

I wonder if you're not looking for path_to_local(peel_casts(expr)), where peel_casts() is currently defined in clippy_lints/src/transmute/transmute_null_to_fn.rs.

But I am not sure you need to detect casts to implement the manual_checked_sub lint you are working on, at least for the basic expr1 - expr2 case where expressions are side-effect-free and not both of them are constants.

Yes, peel_casts looks perfect for what I wanted to achieve, thanks a lot. I'll go ahead and close this issue.