trivial_numeric_casts warning incorrect when casting between type aliases

[lilyball]

The new trivial_numeric_casts lint incorrectly warns when casting between two types that happen to be type aliases. This is incorrect because the types may not actually be type aliases under all build configurations. Case in point, libc::c_long is i32 on some architectures and i64 on others. If I believe the trivial_numeric_casts warning when casting from an i64 to a libc::c_long, that breaks compilation on 32-bit architectures.

#![feature(libc)]

extern crate libc;

fn main() {
    let x: i64 = 1;
    let _y = x as libc::c_long;
//           ^~~~~~~~~~~~~~~~~
// warning: trivial numeric cast: `i64` as `i64`, #[warn(trivial_numeric_casts)] on by default
}

[lilyball]

cc @nrc

[lilyball]

The lint was added in #23630

[nikomatsakis]

the idea was that you could "allow" the lint in that case...?

[alexcrichton]

I personally agree that this is such a common use case that I would prefer to not have to #[allow(trivial_numeric_casts)] in all crates that have some form of FFI binding.

[Ryman]

@nikomatsakis There's poor interaction with macros in that case. I had a similar case for function pointer casting, which would require library users to use #![allow(..)] in their crates which use nickel.

It's along the lines of http://is.gd/8ZfS1I

[eddyb]

What about an attribute (maybe #[allow(trivial_numeric_casts)] itself, but that might not work) on the types aliases which may vary between compilations?

[nrc]

This is correct behaviour (according to the RFC). We warn if it is a trivial cast, we don't take account of what type aliases might be under different configurations (I'm not even sure we could). If you are doing these kind of casts, you should just use #[allow(trivial_numeric_casts)].

Closing, since this is correct behaviour. Please file an RFC issue if you think the spec'ed behaviour is incorrect.

[alexcrichton]

I've opened an RFC issue about this: rust-lang/rfcs#1020