-
Notifications
You must be signed in to change notification settings - Fork 752
Support deriving copy for large array #874
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,37 @@ | ||
/* automatically generated by rust-bindgen */ | ||
|
||
|
||
#![allow(dead_code, non_snake_case, non_camel_case_types, non_upper_case_globals)] | ||
|
||
|
||
#[repr(C)] | ||
#[derive(Copy)] | ||
pub struct S { | ||
pub large_array: [::std::os::raw::c_char; 33usize], | ||
} | ||
#[test] | ||
fn bindgen_test_layout_S() { | ||
assert_eq!(::std::mem::size_of::<S>() , 33usize , concat ! ( | ||
"Size of: " , stringify ! ( S ) )); | ||
assert_eq! (::std::mem::align_of::<S>() , 1usize , concat ! ( | ||
"Alignment of " , stringify ! ( S ) )); | ||
assert_eq! (unsafe { | ||
& ( * ( 0 as * const S ) ) . large_array as * const _ as usize | ||
} , 0usize , concat ! ( | ||
"Alignment of field: " , stringify ! ( S ) , "::" , stringify | ||
! ( large_array ) )); | ||
} | ||
impl Clone for S { | ||
fn clone(&self) -> Self { *self } | ||
} | ||
impl Default for S { | ||
fn default() -> Self { unsafe { ::std::mem::zeroed() } } | ||
} | ||
#[repr(C)] | ||
pub struct ST<T> { | ||
pub large_array: [T; 33usize], | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, so why did this suddenly start working? There have been multiple refactors of the derive debug code, @fitzgen, do you know which one could cause this? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @emilio I'm unsure what "this" that suddenly started working is? We aren't deriving There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I meant that the length check was effectively fixing that, so it eventually became unneeded, and I wondered if you knew off-hand why :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. From my memory, deriving |
||
pub _phantom_0: ::std::marker::PhantomData<::std::cell::UnsafeCell<T>>, | ||
} | ||
impl <T> Default for ST<T> { | ||
fn default() -> Self { unsafe { ::std::mem::zeroed() } } | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
struct S { | ||
char large_array[33]; | ||
}; | ||
|
||
template<typename T> struct ST { | ||
T large_array[33]; | ||
}; |
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually
bindgen
derivedCopy
for incomplete array even before this change. The reason some of the structs with incomplete array in previous tests have not been derivingCopy
is that they also contain large arrays...This will disallow previous allowed deriving of
Copy
though if it contains an incomplete array.So this pull requests now actually makes two conceptually different changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then this was a pretty egregious bug; pretty sad we didn't catch that :(
Definitely shouldn't be deriving
Copy
for incomplete arrays, as we have no idea what the correct thing to do in the scenario is...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we could discern incomplete arrays vs zero-sized arrays that get used as a field separator, but seems safer to just avoid it for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think before variable length array (the name used for incomplete array) gets into C99, zero-sized array is used as a hack to achieve the same effect? If so, maybe we should not assume zero-sized array is not used as incomplete array?