You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There seems to be inconsistent behavior for derive_default based on whether the type is detected to be opaque by bindgen or explicitly marked as opaque by bindgen.
For a C definition of struct Foo; for an opaque struct, bindgen will generate the following with derive_default(true):
I don't see why explicitly marking the type as opaque should change whether or not Default is derived. I also think that it makes even less sense that Default gets derived for a type that is supposed to be Opaque, since opaque types should never be directly accessed and should be handled only via pointers.
Other Information
rust-bindgen 0.71.1
clang version 19.1.7
Target: x86_64-pc-windows-msvc
Full Code Sample build.rs:
use std::env;use std::path::PathBuf;fnmain(){
tracing_subscriber::fmt::init();let builder = bindgen::Builder::default().header_contents("input.h",r#"struct Foo;struct BAR__{int unused;};typedef struct BAR__ *BAR;"#,).parse_callbacks(Box::new(bindgen::CargoCallbacks::new())).derive_default(true);let out_path = PathBuf::from(env::var("OUT_DIR").unwrap());
builder
.clone().generate().expect("Unable to generate bindings").write_to_file((out_path).join("not-explicit-opaque.rs")).expect("Couldn't write bindings!");
builder
.opaque_type("Foo").opaque_type("BAR__")// Only BAR__ should be marked as opaque. The convenience type BAR should remain as a pointer to the opaque BAR__. .generate().expect("Unable to generate bindings").write_to_file((out_path).join("explicit-opaque.rs")).expect("Couldn't write bindings!");}
Output: not-explicit-opaque.rs:
/* automatically generated by rust-bindgen 0.71.1 */#[repr(C)]#[derive(Debug,Copy,Clone)]pubstructFoo{_unused:[u8;0],}#[repr(C)]#[derive(Debug,Default,Copy,Clone)]pubstructBAR__{pubunused:::std::os::raw::c_int,}#[allow(clippy::unnecessary_operation, clippy::identity_op)]const _:() = {["Size of BAR__"][::std::mem::size_of::<BAR__>() - 4usize];["Alignment of BAR__"][::std::mem::align_of::<BAR__>() - 4usize];["Offset of field: BAR__::unused"][::std::mem::offset_of!(BAR__, unused) - 0usize];};pubtypeBAR = *mutBAR__;
explicit-opaque.rs:
/* automatically generated by rust-bindgen 0.71.1 */#[repr(C)]#[derive(Debug,Default,Copy,Clone)]pubstructFoo{_unused:[u8;0],}#[repr(C)]#[repr(align(4))]#[derive(Debug,Default,Copy,Clone)]pubstructBAR__{pub_bindgen_opaque_blob:u32,}#[allow(clippy::unnecessary_operation, clippy::identity_op)]const _:() = {["Size of BAR__"][::std::mem::size_of::<BAR__>() - 4usize];["Alignment of BAR__"][::std::mem::align_of::<BAR__>() - 4usize];};pubtypeBAR = *mutBAR__;
Output Diff (left is no explicit opaque. right is explicit opaque):
The text was updated successfully, but these errors were encountered:
Opaque types shouldn't derive any of Copy, Clone or default. See also: #1656.
( I have some patches related to opaque types on my fork of bindgen, but didn't have the time yet to clean the ones related to opaque types up enough to open a PR)
There seems to be inconsistent behavior for
derive_default
based on whether the type is detected to be opaque by bindgen or explicitly marked as opaque by bindgen.For a C definition of
struct Foo;
for an opaque struct,bindgen
will generate the following withderive_default(true)
:When
Foo
is also explicitly marked opaque with.opaque_type("Foo")
, it generates the following:I don't see why explicitly marking the type as opaque should change whether or not
Default
is derived. I also think that it makes even less sense thatDefault
gets derived for a type that is supposed to be Opaque, since opaque types should never be directly accessed and should be handled only via pointers.Other Information
rust-bindgen 0.71.1
clang version 19.1.7
Target: x86_64-pc-windows-msvc
Full Code Sample
build.rs
:Output:
not-explicit-opaque.rs
:explicit-opaque.rs
:Output Diff (left is no explicit opaque. right is explicit opaque):
![Image](https://private-user-images.githubusercontent.com/16629657/406272290-e7b2bf6a-44b3-40de-962f-321d8cc62261.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkzMDgzNTQsIm5iZiI6MTczOTMwODA1NCwicGF0aCI6Ii8xNjYyOTY1Ny80MDYyNzIyOTAtZTdiMmJmNmEtNDRiMy00MGRlLTk2MmYtMzIxZDhjYzYyMjYxLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMTElMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjExVDIxMDczNFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTllNzkyZTU5YTI3OGVmYWM3ZTRhMWY5ZDEzMTU4ZjY0MThjOTJiNWQyYzczNTJiOGUzMjA2ZDdlNWE1NDI0MjcmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.QsyRJfCXPIm2pl9J74zkxjINdZl5j5a7Phfftd_PCQE)
The text was updated successfully, but these errors were encountered: