Lots of incorrect useless_conversion warnings when libc is involved

[mahkoh]

I tried this code:

    let cmsg_len = match usize::try_from(hdr.cmsg_len) {
        Ok(l) => l,
        _ => return einval(),
    };

I expected to see this happen: Nothing, as cmsg_len is u32 on many platforms.

Instead, this happened:

warning: useless conversion to the same type: `usize`
  --> uapi/src/socket/cmsg.rs:71:26
   |
71 |     let cmsg_len = match usize::try_from(hdr.cmsg_len) {
   |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: consider removing `usize::try_from()`
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#useless_conversion

Meta

• cargo clippy -V: clippy 0.0.212 (7eac88a 2020-11-16)
• rustc -Vv:

   rustc 1.48.0 (7eac88abb 2020-11-16)
   binary: rustc
   commit-hash: 7eac88abb2e57e752f3302f02be5f3ce3d7adfb4
   commit-date: 2020-11-16
   host: x86_64-unknown-linux-gnu
   release: 1.48.0
   LLVM version: 11.0
  

[camsteffen]

I may be missing something, but why can't you just remove try_from like the lint suggests? In your example, you are converting cmsg_len which is size_t and size_t is an alias for usize. I don't see any #[cfg] attributes that would change those types for other platforms.

[kalcutter]

size_t and usize are semantically distinct types. There may be platforms where they differ now or in the future. Assuming they are the same type is a bug (clippy should have a lint for this).

See also: rust-lang/libc#1400

[estebank]

I found a way of addressing the false-positives in rust-lang/rust#129249, at the cost of false-negatives. By detecting imports that are annotated with #[cfg] or behind a cfg_select!, and looking at explicitly imported type aliases annotated the same way, and keeping their resolved types in an ignore-list, we can avoid linting on types like c_int. The problem with this is that the crate might also include conversions from i32 to itself that do not involve c_int, and those would not be picked up. I think it makes sense to follow the same strategy I'm following in that PR (with the detection within macro expansions case) and split the lint into multiple ones with different lint levels commensurate with our confidence level.

More accurate tracking (that the conversion is being done on a value that is c_int or size_t and not i32 or usize) would require reworking how the type system handles type aliases internally.