Add new function_casts_as_integer lint

[GuillaumeGomez]

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]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[flip1995]

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 🤔

[GuillaumeGomez]

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.

[flip1995]

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?

[GuillaumeGomez]

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.

[flip1995]

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

[GuillaumeGomez]

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

[traviscross]

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

[traviscross]

See also:

• API for explicitly getting an opaque pointer of a function libs-team#589
  • ...and particularly API for explicitly getting an opaque pointer of a function libs-team#589 (comment)
• Tracking Issue for ptr::fn_addr_eq #129322

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 _;
}

[bors]

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

[GuillaumeGomez]

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).

[joshtriplett]

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]

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

[joshtriplett]

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]

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]

@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]

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]

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.

[GuillaumeGomez]

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?