rust-lang / rust-bindgen

Automatically generates Rust FFI bindings to C (and some C++) libraries.
https://rust-lang.github.io/rust-bindgen/
BSD 3-Clause "New" or "Revised" License
4.5k stars 700 forks source link

Silently wrong code generated for enums in templated classes #2871

Open tschneidereit opened 4 months ago

tschneidereit commented 4 months ago

Input C/C++ Header

template <typename T>
class Test {
  enum class Enum { One, Two };
};

Bindgen Invocation

Tested both with the current release and current main:

$ bindgen input.h -- -x c++ -std=c++11

Actual Results

/* automatically generated by rust-bindgen 0.69.4 */

#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct Test {
    pub _address: u8,
}
pub const Test_Enum_One: Test_Enum = 0;
pub const Test_Enum_Two: Test_Enum = 0;
pub type Test_Enum = ::std::os::raw::c_int;

Expected Results

I would expect to see the same enum generated as for a non-templated class. Removing the first line of input.h results in this generated code:

/* automatically generated by rust-bindgen 0.69.4 */

#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct Test {
    pub _address: u8,
}
pub const Test_Enum_One: Test_Enum = 0;
pub const Test_Enum_Two: Test_Enum = 1;
pub type Test_Enum = ::std::os::raw::c_int;
#[test]
fn bindgen_test_layout_Test() {
    assert_eq!(
        ::std::mem::size_of::<Test>(),
        1usize,
        concat!("Size of: ", stringify!(Test))
    );
    assert_eq!(
        ::std::mem::align_of::<Test>(),
        1usize,
        concat!("Alignment of ", stringify!(Test))
    );
}
tschneidereit commented 4 months ago

I just realized that this is covered by a test since #1444. @scoopr and @emilio, am I missing a reason for why this behavior is indeed correct? I see no discussion of this part of the PR.

scoopr commented 4 months ago

Ah, are you referring specifically to the enum value? That indeed looks suspicious, and I might of missed it when I was worrying about the duplication of the types, and just trusted the value generated. This was quite a while ago and I can't quite recall precisely.

emilio commented 4 months ago

Yeah, I think the value is wrong, but in this case it's likely clang lying to us about what the value is unfortunately... Would need to debug this properly, but it's a bug.