dead_code lint warns about struct fields it can't actually know are dead due to C FFI

[lilyball]

The dead_code lint has started warning about struct fields, in 9bb8f88. The problem is, it does this even if it can't guarantee the field is actually dead. Notably, it warns about struct fields for structs that are passed as *mut pointers to C FFI functions. In this case, my Rust code only zero-initializes the field, and never reads it because it's purely for use by the C FFI function.

This reproduces with lilyball/rust-lua@be46e268c with the lua_Debug struct (in raw.rs). It has a single private field that's used by the Lua C functions internally, and is intentionally not touched (beyond being zero-initialized) by the Rust code.

I think the solution here is for the dead_code lint to assume that any extern { fn } that takes a *mut pointer to a struct may potentially use every field of the struct, and therefore to treat any fields of structs with said C FFI functions as live regardless of whether the Rust code touches them.

[lilyball]

/cc @jakub-. The PR that introduced this behavior was #14696.

[lilyball]

Hrm, ok I just took another look, and apparently #[repr(C)] squelches this warning. I didn't know that was already accepted as a non-unused annotation. There's been no activity on the tracking issue #14309 for the relevant RFC.

#14309 includes adding a lint for warning about non-#[repr(C)] structs that are used with C FFI. Perhaps that should be fast-tracked and implemented now even if no other work towards #14309 is going to be done in the short term, if that's the intended way to deal with this spurious dead_code warning.

/cc @cmr

[alexcrichton]

Closing in favor of #14309. As you realized, #[repr(C)] turns off all the warnings, and once #14309 is implemented you will also have warnings for where you need to write #[repr(C)], which should turn down the noise on these warnings greatly.

[alexcrichton]

If #14309 isn't implemented in a timely manner we can revisit opening this.