Skip to content

Add new function_casts_as_integer lint #141470

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

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

GuillaumeGomez
Copy link
Member

@GuillaumeGomez GuillaumeGomez commented May 23, 2025

The function_casts_as_integer lint detects cases where users cast a function pointer into an integer.

warn-by-default

Example

fn foo() {}
let x = foo as usize;
warning: casting a function into an integer implicitly
  --> $DIR/function_casts_as_integer.rs:9:17
   |
LL |     let x = foo as usize;
   |                 ^^^^^^^^
   |
help: add `fn() as usize`
   |
LL |     let x = foo as fn() as usize;
   |                 +++++++

Explanation

You should never cast a function directly into an integer but go through a cast as fn first to make it obvious what's going on. It also allows to prevent confusion with (associated) constants.

Related to #81686 and https://stackoverflow.com/questions/68701177/whats-the-meaning-of-casting-a-rust-enum-variant-to-a-numeric-data-type

r? @Urgau

@rustbot rustbot added O-unix Operating system: Unix-like S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels May 23, 2025
@rust-log-analyzer

This comment has been minimized.

@GuillaumeGomez GuillaumeGomez force-pushed the function_casts_as_integer branch 2 times, most recently from 07f2c3c to 4978962 Compare May 23, 2025 20:54
@rust-log-analyzer

This comment has been minimized.

@GuillaumeGomez GuillaumeGomez force-pushed the function_casts_as_integer branch 2 times, most recently from 3db3153 to d8b1955 Compare May 24, 2025 10:10
@rust-log-analyzer

This comment has been minimized.

@Urgau Urgau added T-lang Relevant to the language team and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels May 24, 2025
@GuillaumeGomez GuillaumeGomez force-pushed the function_casts_as_integer branch from d8b1955 to 45984df Compare May 24, 2025 18:45
@rust-log-analyzer

This comment has been minimized.

@GuillaumeGomez GuillaumeGomez force-pushed the function_casts_as_integer branch from 45984df to a6107b4 Compare May 24, 2025 19:09
@rust-log-analyzer

This comment has been minimized.

@GuillaumeGomez GuillaumeGomez force-pushed the function_casts_as_integer branch from a6107b4 to 24d757e Compare May 24, 2025 22:47
@rustbot
Copy link
Collaborator

rustbot commented May 24, 2025

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

@rust-log-analyzer

This comment has been minimized.

@Urgau Urgau added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 26, 2025
@GuillaumeGomez GuillaumeGomez force-pushed the function_casts_as_integer branch from 24d757e to 3529162 Compare May 27, 2025 14:12
@rustbot
Copy link
Collaborator

rustbot commented May 27, 2025

The Miri subtree was changed

cc @rust-lang/miri

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

/// a cast as `fn` first to make it obvious what's going on. It also allows
/// to prevent confusion with (associated) constants.
pub FUNCTION_CASTS_AS_INTEGER,
Warn,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clippy has a few lints for fn to integer casts. But they are all restriction or style lints in Clippy. Adding a warn-by-default lint about this to rustc might be a bit aggressive 🤔

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know, I implemented one myself. 😉 I think it highlights the fact that this is a big issue and that the compiler should warn about it and eventually even forbid this fn to integer cast (you need to cast to an fn pointer first).

But in any case, it's up to the lang team.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed 👍 Just want to add this information as "prior art" for the lang team to make this decision. Even though it might've sounded like it, I'm not against adding this lint to rustc.

Clippy question: Do you think if this lint gets added to rustc, we can (partially) deprecate Clippy lints?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hard to say. For example confusing_method_to_numeric_cast provides extra information about what (likely) went wrong. But with the current lint, they likely would already have seen the problem and fixed it. So by default I'd say yes. But we could eventually uplift part of them to add the extra context clippy has that this lint doesn't provide. Would make it much more interesting and even more useful.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, a partial uplift might be good then, should this be accepted.

@rustbot rustbot added I-lang-radar Items that are on lang's radar and will need eventual work or consideration. and removed I-lang-nominated Nominated for discussion during a lang team meeting. labels Jun 6, 2025
@GuillaumeGomez
Copy link
Member Author

Sorry but I disagree, you can just copy what the lint tells you. The whole point is to have these annotations appear in the code, in part to prevent confusing associated items with methods. So putting back the nomination.

@rustbot labels -I-lang-radar +I-lang-nominated

@rustbot rustbot added I-lang-nominated Nominated for discussion during a lang team meeting. and removed I-lang-radar Items that are on lang's radar and will need eventual work or consideration. labels Jun 6, 2025
@traviscross traviscross added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). needs-fcp This change is insta-stable, or significant enough to need a team FCP to proceed. I-lang-radar Items that are on lang's radar and will need eventual work or consideration. and removed I-lang-nominated Nominated for discussion during a lang team meeting. labels Jun 6, 2025
@traviscross
Copy link
Contributor

OK. Fair enough. We can discuss. What are your thoughts on the mentioned interaction with #140803 though?

@traviscross traviscross added I-lang-nominated Nominated for discussion during a lang team meeting. P-lang-drag-3 Lang team prioritization drag level 3.https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang. labels Jun 6, 2025
@traviscross
Copy link
Contributor

traviscross commented Jun 6, 2025

See also:

I'm curious too what your thoughts are about these:

fn f() {}

fn main() {
    let x: usize = (&raw const *&f) as _;
    let x: usize = (&raw const *&f) as *const () as _;
    let x: usize = f as *const () as _;
}

@Urgau Urgau removed O-windows Operating system: Windows S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. O-unix Operating system: Unix-like labels Jun 7, 2025
@bors
Copy link
Collaborator

bors commented Jun 9, 2025

☔ The latest upstream changes (presumably #141700) made this pull request unmergeable. Please resolve the merge conflicts.

@GuillaumeGomez
Copy link
Member Author

Interesting discussion, in particular the cast from integer to function. Although I think it's a different problem as the compiler currently doesn't allow it (casting from integer to function), unlike the current code which adds a warning for a cast from function to integer.

There are multiple clippy lints to check for this issue, which proves that there is a big need for this silent issue.

So the goal here is to prevent having an involuntary cast of a function to an integer. Now about the code you provided:

fn f() {}

fn main() {
    let x: usize = (&raw const *&f) as _;
    let x: usize = (&raw const *&f) as *const () as _;
    let x: usize = f as *const () as _;
}

For me it presents one big issue: we cannot assume from this code that f is a function without more context. It could also silence the issue we're trying to address. I think enforcing an explicit cast is the best way (even more considering the lint shows exactly what the cast needs to be).

@traviscross traviscross added P-lang-drag-2 Lang team prioritization drag level 2.https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang. and removed P-lang-drag-3 Lang team prioritization drag level 3.https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang. labels Jul 2, 2025
@joshtriplett
Copy link
Member

It seems, to me, like there are two separate questions here:

  • Should we lint about writing func as usize?
  • What should we recommend that people write instead to make it explicit?

The first question seems easy: "yes". The second question is extremely bikesheddable.

I'd like to see us separate these questions in our discussion, and decide the first in principle before we start bikeshedding the second.

As a reminder, the goal of such a lint is to catch things like u32::max as usize (which likely wanted to be u32::MAX as usize).

@GuillaumeGomez
Copy link
Member Author

Sounds good to me. And agreed, second question will likely be the most difficult to agree upon.

@joshtriplett
Copy link
Member

In the spirit of our long-term goals of eliminating as, could we add a method here on functions, func.method_name() (name TBD), which returns a usize, and whose name clearly identifies that it's a function? e.g. something like func.fn_addr().

@GuillaumeGomez
Copy link
Member Author

That seems related but separated from the current goal of this PR, no? More like a second step. First we warn for this as cast, second we can provide a suggestion saying that if they actually want the address, they can use this newly added method on functions to cast the function address into a usize. What do you think?

@joshtriplett
Copy link
Member

joshtriplett commented Jul 9, 2025

@GuillaumeGomez I was proposing it in part because it might make it easier for us to agree that we have a better alternative to the as-cast. And if we know that's where we want to get to, then we might not want the churn of driving people towards as something as usize and then towards .fn_addr().

Definitely not looking to make the perfect the enemy of the good, here. Rather, trying to make sure we have a sufficient good that people feel motivated to warn about as usize.

@GuillaumeGomez
Copy link
Member Author

Yeah, thinking some more about it today, I agree with you. If the libs team is ok with the addition of this new method on fn types, then I can send a PR. My only issue is that we'll need for this new method to be stabilized, and in the meantime, the current issue will remain. I suppose we suggest the new method on nightly and the longer version until then to reduce this delay?

@joshtriplett
Copy link
Member

joshtriplett commented Jul 9, 2025

We have an accepted ACP for an API that would work for this: rust-lang/libs-team#589 (comment)

We'd like to see a lint based on this, and attempt to ship and stabilize that API in a timely fashion.

If that API ends up taking longer than expected, we'd also approve an interim lint catching specific cases like the integer max/min functions.

@traviscross traviscross removed I-lang-nominated Nominated for discussion during a lang team meeting. P-lang-drag-2 Lang team prioritization drag level 2.https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang. labels Jul 9, 2025
@GuillaumeGomez
Copy link
Member Author

Then I can send a PR to implement this new API as a first step if it's ok with you and we'll see the next step once merged?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-lang-radar Items that are on lang's radar and will need eventual work or consideration. needs-fcp This change is insta-stable, or significant enough to need a team FCP to proceed. S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants