Providing information about integer type aliases with multiple sizes

Description

In projects like the Linux kernel, there are type aliases (e.g. coming from the C side, generated by bindgen) that are integers with different sizes depending on the architecture, e.g. a C resource_size_t may end up being u32 or u64 in Rust.

When dealing with these types, we end up with cases where we may want to e.g. widen the C type in the 32-bit case, while having a no-op for the 64-bit case, thus we may want to call into() to end up always with a u64 like in this case:

getparam.set_value(value.into());

However, here, Clippy's useless_conversion will complain about this when building for 64-bit. Thus we may use an allow (or a conditional expect).

That works fine, but we were wondering whether it would make sense to give information to the compiler about these integers with multiple possible lengths, so that it can use that information for its diagnostics.

For instance, it could allow Clippy to avoid linting in the case above, since it will know it is not always a useless conversion.

On the other hand, in the case above, relaxing a lint like that would mean that e.g. an into() is now a bit more ambiguous, i.e. currently when developers see an into() they know it cannot be a no-op in any architecture (assuming we build with Clippy for those architectures). Thus it may be best to have an explicit function to perform such widening (or going for a newtype etc.) anyway.

Version

rustc 1.88.0 (6b00bc388 2025-06-23)

Additional Labels

@rustbot label +C-question

Start with Clippy's useless_conversion lint and investigate how Rust represents integer aliases whose sizes vary across target architectures. Compare compiler-provided type information with explicit widening or a newtype, and establish whether the desired behavior is a lint change or a broader language design. Done requires an agreed design, implementation scope, and target-specific tests.