Open wmmc88 opened 3 months ago
Which rust version are you using? We have code to deal with this, see https://github.com/rust-lang/rust-bindgen/commit/a380678490b821201f10b861144b15bbe08694a2
Ah, so I couldn't repro this, but that's because for some reason --target=x86_64-pc-win32
is needed to repro:
./target/debug/bindgen --with-derive-default t.h -- --target=x86_64-pc-win32
Is the command I used to reproduce. It seems the MONITORINFO;
line is kind of like a member, but it's unnamed and clang doesn't expose it as such... o.O
And somehow that only happens when targeting windows
I think that limitation in rustc is mostly historical? https://github.com/rust-lang/rust/pull/124163 removes it.
@emilio
Which rust version are you using? We have code to deal with this, see https://github.com/rust-lang/rust-bindgen/commit/a380678490b821201f10b861144b15bbe08694a2
I'm able to repro on latest stable(stable-x86_64-pc-windows-msvc unchanged - rustc 1.77.2 (25ef9e3d8 2024-04-09)
), beta(beta-x86_64-pc-windows-msvc updated - rustc 1.78.0-beta.7 (6fd191292 2024-04-12) (from rustc 1.78.0-beta.5 (9eff51035 2024-04-06))
), and nightly(nightly-x86_64-pc-windows-msvc updated - rustc 1.79.0-nightly (e3181b091 2024-04-18) (from rustc 1.79.0-nightly (8b2459c1f 2024-04-09))
). I'm assuming this is some sort of regression.
Ah, so I couldn't repro this, but that's because for some reason --target=x86_64-pc-win32 is needed to repro:
I am using x64 windows w/ msvc toolchain, so my native target is x86_64-pc-windows-msvc
I've also tried enabling clang's msvc compat, and it doesn't alter behavior here:
.clang_args([
"-fms-compatibility",
"-fms-extensions",
"-fdelayed-template-parsing",
])
@emilio looks like your proposed patch to rust was rejected. Can this continue to be handled by bindgen?
I think this issue is a bit deeper than just a missing Default
implementation. If we had something like this:
// hello.c
typedef struct bar {
int *a[17];
} bar;
typedef struct foo {
bar;
int b;
} foo;
and ran bindgen hello.c --with-derive-default --no-layout-tests -- --target=x86_64-pc-windows-mvsc -fms-extensions
you'd get:
/* automatically generated by rust-bindgen 0.69.4 */
#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct bar {
pub a: [*mut ::std::os::raw::c_int; 17usize],
}
impl Default for bar {
fn default() -> Self {
let mut s = ::std::mem::MaybeUninit::<Self>::uninit();
unsafe {
::std::ptr::write_bytes(s.as_mut_ptr(), 0, 1);
s.assume_init()
}
}
}
#[repr(C)]
#[repr(align(8))]
#[derive(Debug, Default, Copy, Clone)]
pub struct foo {
pub __bindgen_padding_0: [u32; 34usize],
pub b: ::std::os::raw::c_int,
}
implementing Default
for foo
is most likely wrong as you'd end up with an array of null pointers. I guess this is just a symptom of clang
exposing the anonymous struct inside foo
as an opaque type instead of giving the proper information.
bruh
Input C/C++ Header
Bindgen Invocation
Actual Results
and/or
Expected Results
I expected it to generate a default implementation successfully. This seems to be another regression of #1718/#1719 and #2082, where it fails to generate a valid
Default
when the array has more than the 32 entries (where rust itself generates aDefault
for <=32 entries).