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.

[rustbot]

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

[GuillaumeGomez]

CI finally passed. \o/

[Urgau]

It's by convention always lowercase in the compiler.

Suggested change

	"Casting a function into an integer",
	"casting a function into an integer",

[Urgau]

No need to mention the "users", might be auto-generated code.

Suggested change

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

[Urgau]

This doesn't really explain what is the problem this lint is checking for, ie. why is it bad. What about saying that by casting a function item to an integer it's implicitly creating a function pointer and it's that one that is casted to an integer, and so by making it explicit it improves re-ability of the code and prevents bugs (in particular with enum variants).

[Urgau]

Should be moved to src/lints.rs where all the other #[derive(LintDiagnostic)] struct lives.

[Urgau]

By convention we name these with the Diag suffix.

Suggested change

	struct FunctionCastsAsIntegerMsg<'tcx> {
	struct FunctionCastsAsIntegerDiag<'tcx> {

[Urgau]

unrelated changes?

[Urgau]

same here, unrelated changes?

[Urgau]

Better not changing the lint level in it's main test.

Suggested change

	#![deny(function_casts_as_integer)]
	//@ check-pass

[Urgau]

Could you also add tests for enum variants.

enum MyEnum {
    Variant,
}

let _a = MyEnum::Variant as usize; //~ WARN: function_casts_as_integer