Skip to content

extend clippy_utils::path_to_local() to handle Cast expressions #14378

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

Closed
benacq opened this issue Mar 8, 2025 · 4 comments
Closed

extend clippy_utils::path_to_local() to handle Cast expressions #14378

benacq opened this issue Mar 8, 2025 · 4 comments

Comments

@benacq
Copy link

benacq commented Mar 8, 2025

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
Copy link
Contributor

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
Copy link
Author

benacq commented Mar 9, 2025

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
Copy link
Contributor

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
Copy link
Author

benacq commented Mar 9, 2025

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.

@benacq benacq closed this as not planned Won't fix, can't repro, duplicate, stale Mar 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants