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.

[traviscross]

@rfcbot reviewed

[nikomatsakis]

@rfcbot reviewed

I believe it would be better to give people a more ergonomic expansion (I hate the "cast to raw then cast to usize" pattern) as well as guiding people away from mixing code/data pointers, but we can't have perfect be enemy of good here.

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[tmandry]

@rfcbot reviewed

I believe it would be better to give people a more ergonomic expansion (I hate the "cast to raw then cast to usize" pattern) as well as guiding people away from mixing code/data pointers, but we can't have perfect be enemy of good here.

Agreed.

[joshtriplett]

I believe it would be better to give people a more ergonomic expansion (I hate the "cast to raw then cast to usize" pattern) as well as guiding people away from mixing code/data pointers, but we can't have perfect be enemy of good here.

Complete agreement.

[GuillaumeGomez]

Still think we should keep the function pointer appear in the cast expression to make it possible to understand what's actually happening (because x as *const () can be literally anything) but I guess it's better than nothing. Hopefully we'll have a better suggestion later on once the new trait will be available.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[GuillaumeGomez]

So now it accepts all function to pointer casts and suggest as *const () as usize.

[traviscross]

Suggested change

	/// The `function_casts_as_integer` lint detects cases where a function item is casted
	/// into an integer.
	/// The `function_casts_as_integer` lint detects cases where a function item is cast
	/// to an integer.

[traviscross]

Suggested change

	/// When casting a function item into an integer, it's implicitly creating a
	/// When casting a function item to an integer, it implicitly creates a

[traviscross]

Suggested change

	/// function pointer that will in turn be casted into an integer. By making
	/// function pointer that will in turn be cast to an integer. By making

[GuillaumeGomez]

Fixed typos.