feat: add cast_ptr_sized_int lint

[ab22593k]

Introduce a new restriction lint to identify casts between pointer-sized integer types (usize, isize) and fixed-size integer types.

Encourage the use of TryFrom or TryInto over direct as casts to make potential platform-specific truncation or zero-extension explicit and handled.

Also Provide machine-applicable suggestions to replace risky casts with fallible conversions while excluding constant contexts where such traits are not yet stable.

Closes: #9231

changelog: add cast_ptr_sized_int lint

[rustbot]

r? @samueltardieu

rustbot has assigned @samueltardieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[github-actions]

Lintcheck changes for 3a6e6b3

Lint	Added	Removed	Changed
clippy::cast_ptr_sized_int	1382	0	0

This comment will be updated if you push new changes

[samueltardieu]

Aren't those cases already covered by the cast_lossless, cast_possible_truncation, cast_possible_wrap, and cast_sign_loss lints?

Moreover, the suggestion transforms integer types into options, which is not a directly applicable fix.

View changes since this review

[samueltardieu]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[ab22593k]

This is exactly the gap the lint addresses: If you compile on 64-bit, usize as u64 looks safe. But the same code behaves differently on 32-bit. No existing lint catches this architecture-dependent behavior.

The suggestion is not directly applicable: should i remove the suggestion (just warn without providing a fix)?

[samueltardieu]

The lint still triggers inconsistently. For example:

• usize can also be a 16-bit integer on some tier 3 platforms such as MSP430
• A cast from u8 or u16 to usize will always succeed and should not be warned about
• A cast from usize to u64 or u128 will always succeed and should not be warned about

And indeed, no fix should be provided if it would be incorrect, but the help message may suggest using try_from() and let the user act on it.

[ab22593k]

@rustbot ready

[samueltardieu]

If you add

#![deny(clippy::cast_lossless, clippy::cast_possible_truncation, clippy::cast_possible_wrap, clippy::cast_sign_loss)]

at the top of your test file, you'll see that most of the lines that your PR lints will already be linted.

I wonder if it would be more useful to extend existing lints with an additional configuration option to warn when pointer sized ints could cause issues even though they don't on the platform on which they are compiled.

Maybe the user could even specify the range of sizes it is interested in compiling for. For example, target_usize_supported_bounds = [32, 64] would let the user indicate that they are not interested in compiling for 16 bit platforms, and the lint should report an error if the current platform is outside this range.

What do you think?

View changes since this review

[samueltardieu]

Why is this needed?

[ab22593k]

Sorry; just keep #![warn(clippy::cast_ptr_sized_int)]

[samueltardieu]

The message is not great here: casting usize to u8 will always truncate.

[ab22593k]

Fixed

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

[ab22593k]

I think the extend cast_possible_truncation with platform bounds configuration is more is compelling.

clippy.toml Configuration:
target_pointer_widths = [32, 64] # Platforms the user targets
Default: [16, 32, 64] # Warns for all platforms

With proposed Error message with target_pointer_widths = [32, 64] like:
casting u64 to usize may truncate the value on 32-bit platforms

Benefits: No duplication. User control. Leverages existing code

[ab22593k]

@rustbot ready

[samueltardieu]

There are still cases where it will conflict with those three pedantic lints: cast_possible_truncation and cast_possible_wrap, and even cast_sign_loss (e.g., when casting a i64 to usize).

We'll have to find a way to trigger either one or the other lint. If this new lint was a restriction lint, it would make sense to try it first and make it return a boolean if it effectively lints, and execute the other three only when this one didn't post a warning.

View changes since this review

[rustbot]

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