Dead code pass no longer considers enum used in `pub extern "C" fn` as used

[chinedufn]

A repository that I maintain recently received a bug report about our proc macro generating a warning after they upgraded to 1.79.0.

I haven't bisected for the exact commit that introduces the warning, but I have been able to reproduce it in 1.79.0.

Minimal Reproduction

fn main() {}

mod private_mod {
    #[repr(C)]
    pub enum MyEnum {
        Variant(u32)
    }
    
    #[no_mangle]
    pub extern "C" fn some_function() -> MyEnum {
        MyEnum::Variant(5)
    }
}

   Compiling playground v0.0.1 (/playground)
warning: field `0` is never read
 --> src/main.rs:6:17
  |
6 |         Variant(u32)
  |         ------- ^^^
  |         |
  |         field in this variant
  |
  = note: `#[warn(dead_code)]` on by default
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
  |
6 |         Variant(())
  |                 ~~

warning: `playground` (bin "playground") generated 1 warning
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.85s
     Running `target/debug/playground`

In the playground -> https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3f5c81c0749130a6e46fbea14cbb055f

Potential Candidates

This comment links to some rustc commits that may have introduced the issue chinedufn/swift-bridge#278 (comment)

As mentioned, I haven't taken the time to bisect since I know that it's possible that a core maintainer already has a good sense of when/how this regression could have been introduced.

[jieyouxu]

Also tagging T-lang on this because this involves user-observable changes to the dead_code lint. Feel free to readjust as appropriate.

[chinedufn]

Just updated to the latest nightly and came across another similar regression:

// src/lib.rs

pub mod module {
    #[repr(C)]
    pub struct Foo(u32);
}

No warning on stable 1.79.0

Has a warning on latest nightly (I haven't bisected)

---

Stable (no warning) -> https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=08aa241f1e1544fae1c50f66d16c94f6
Nightly (warning) -> https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=9cacd97f9ce149c18cfd8f2e5052032a

Here is the output on nightly-2024-07-02:

   Compiling playground v0.0.1 (/playground)
warning: struct `Foo` is never constructed
 --> src/main.rs:4:16
  |
4 |     pub struct Foo(u32);
  |                ^^^
  |
  = note: `#[warn(dead_code)]` on by default

warning: `playground` (bin "playground") generated 1 warning
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.38s
     Running `target/debug/playground`

---

Ah, actually the pub mod my_mod { .. } wrapper isn't necessary to reproduce the warning.

Here's an illustration of code that we don't want to lead to a warning, but does on latest nightly.

// crate `foo`'s src/lib.rs

#[repr(C)]
pub struct Foo(u32);
    
impl Foo{
    pub fn print(&self) {
        println!("{}", self.0)
    }
}

It isn't dead code because another crate might use Foo like this:

// In another crate that depends on crate `foo` above
#[no_mangle)
pub extern "C" fn print_foo(foo: Foo) {
    foo.print();
}

[traviscross]

Regarding the original report, this doesn't seem related to extern "C". E.g., this also warns:

mod private_mod {
    pub enum MyEnum {
        Variant(u32)
        //~^ WARN field `0` is never read
    }

    pub fn some_function() -> MyEnum {
        MyEnum::Variant(5)
    }
}

fn main() {
    let _ = private_mod::some_function();
}

And the warning is correct. The field is never read. If you read the field, the warning goes away, both here and in your original example.

Regarding your second example, the warning there also seems correct. The Foo struct has a private field, and it's never constructed. If you make that field public, the warning disappears:

// lib.rs
pub struct Foo(pub u32); //~ No warning

If this analysis understands your report correctly and you agree there's no issue here, then please close the issue.

[chinedufn]

The analysis misunderstands the problem.

In both my first and second example there is a dead code warning for code that is not dead (note that this is the dead_code lint emitting the warning).

---

The reason that the extern "C" is important is that it's what makes the field alive.

In your example code that removes the #[repr(C)] the enum's field is never read.

If you add #[repr(C)] and pass it over FFI then the field might be read by a caller (i.e. a C program) that Rust cannot see.

---

Recall that the error says:

warning: field `0` is never read

When the #[repr(C)] is present, Rust cannot know this.
For instance, a C program might be making use of that field 0.

---

I'm going to add a #[repr(C)] to your pub struct Foo(pub u32) to fully illustrate why it does not solve the problem.

mod foo {
    #[repr(C)]
    pub struct Foo(pub u32);

    impl Foo {
        pub fn new(val: u32) -> Self {
            Self(val)
        }
    }

    pub extern "C" fn return_foo() -> Foo {
        Foo(5);
    }
    // Doubles the value held inside `Foo`
    extern "C" {
        fn double_foo(foo: Foo) -> Foo;
    }
}

fn main() {
    let foo = Foo::new(10);

    // Good. We only want Rust callers to be able to double `Foo`.
    // We don't want them to be able to do anything else.
    let foo = unsafe { foo::double_foo(foo) };

    // BAD: We don't want `Foo`'s internal to be accessible outside of `mod foo`.
    // To solve this, we need to change `pub struct Foo(pub u32)` to `pub struct Foo(u32)`.
    foo.0 = 18;
}

In this example your suggestion changes the semantics of the program.

Foo(pub u32) has broken our intended invariant (Rust users are only able to double the inner value).

---

The simplify:

The reason that this bazz function below is not dead code is that it might be called by a caller that rustc cannot see.

// src/lib.rs
pub function bazz() {}

Similarly, the reason that the #[repr(C)] enum variant is alive in my examples above is alive is that it might be used by a caller that rustc cannot see.

[chinedufn]

Note that this gives us warning:

mod foo {
    #[repr(C)]
    pub enum MyEnum {
        Variant(u32)
    }

    #[no_mangle]
    pub extern "C" fn make_enum() -> MyEnum {
        MyEnum::Variant(10)
    }
}

fn main() {

But this does not warn:

// src/lib.rs

pub enum MyEnum {
    Variant(u32)
}

In the second example rustc is properly recognizing that MyEnum::Variant might be used by a downstream crate.

Similarly, the pub extern "C" fn foo() -> MyEnum {} with #[repr(C)] enum MyEnum { Variant(u32) } means that MyEnum::Variant might be used by some FFI caller.

---

Hoping that all of the above clearly illustrates the problem.

[traviscross]

Regarding your first example, is it correct to say that you believe that this should not warn?:

// lib.rs

#[repr(C, u8)]
enum MyEnum {
    Variant { inner: u8 },
    //~^ WARN field `inner` is never read
}

#[no_mangle]
extern "C" fn some_function() -> MyEnum {
    MyEnum::Variant { inner: 0 }
}

...under the interpretation that the #[no_mangle] should act like #[used] and ensure that some_function ends up in and exported in the object file, and that some program could link this object and some C function could therefore call some_function, get a value of type MyEnum, and, under the RFC 2195 semantics, read the field in that variant?

(According to Godbolt, this program has always produced a warning, which isn't to say whether that's correct or not.)