implicit_constructors.rs panic due to lack of parameters
#923
Comments
|
I'm looking now. |
|
We're declaring something an assignment operator before realizing that we want nothing to do with it because the name is a reserved identifier (double underscores). Those types should get treated as "we don't know what implicit special member functions they have, and we'll ignore the explicit ones that couldn't be parsed, and only look at any other explicit ones". PR coming soon. My notes on how I got there, for future-me or anybody else: It's having trouble with nonesuch. Ironically this is an experimental part of the C++ standard library that has something to do with detecting whether a type has special member functions. cppreference says it's can't be copied, and autocxx is choking on an operator_equals with no arguments. bindgen emits this: #[repr(C)]
#[cpp_semantics(layout(1, 1, false))]
pub struct __nonesuch {
pub _address: u8,
}
extern "C" {
#[cpp_semantics(arg_type_reference(arg1))]
#[cpp_semantics(original_name("operator_equals"))]
#[cpp_semantics(special_member("assignment_operator"))]
#[cpp_semantics(deleted)]
#[link_name = "\u{1}_ZNSt10__nonesuchaSERKS_"]
pub fn __nonesuch_operator_equals(
this: *mut root::std::__nonesuch,
arg1: *const root::std::__nonesuch,
);
}
extern "C" {
#[cpp_semantics(original_name("__nonesuch"))]
#[cpp_semantics(special_member("default_ctor"))]
#[cpp_semantics(deleted)]
#[link_name = "\u{1}_ZNSt10__nonesuchC1Ev"]
pub fn __nonesuch___nonesuch(this: *mut root::std::__nonesuch);
}
extern "C" {
#[cpp_semantics(arg_type_reference(arg1))]
#[cpp_semantics(original_name("__nonesuch"))]
#[cpp_semantics(special_member("copy_ctor"))]
#[cpp_semantics(deleted)]
#[link_name = "\u{1}_ZNSt10__nonesuchC1ERKS_"]
pub fn __nonesuch___nonesuch1(
this: *mut root::std::__nonesuch,
arg1: *const root::std::__nonesuch,
);
}
extern "C" {
#[cpp_semantics(original_name("__nonesuch_destructor"))]
#[cpp_semantics(special_member("dtor"))]
#[cpp_semantics(deleted)]
#[link_name = "\u{1}_ZNSt10__nonesuchD1Ev"]
pub fn __nonesuch___nonesuch_destructor(this: *mut root::std::__nonesuch);
}
impl __nonesuch {
#[cpp_semantics(arg_type_reference(arg1))]
#[inline]
pub unsafe fn operator_equals(&mut self, arg1: *const root::std::__nonesuch) {
__nonesuch_operator_equals(self, arg1)
}
#[inline]
pub unsafe fn new() -> Self {
let mut __bindgen_tmp = ::std::mem::MaybeUninit::uninit();
__nonesuch___nonesuch(__bindgen_tmp.as_mut_ptr());
__bindgen_tmp.assume_init()
}
#[cpp_semantics(arg_type_reference(arg1))]
#[inline]
pub unsafe fn new1(arg1: *const root::std::__nonesuch) -> Self {
let mut __bindgen_tmp = ::std::mem::MaybeUninit::uninit();
__nonesuch___nonesuch1(__bindgen_tmp.as_mut_ptr(), arg1);
__bindgen_tmp.assume_init()
}
#[inline]
pub unsafe fn destruct(&mut self) {
__nonesuch___nonesuch_destructor(self)
}
}The function is deleted, so autocxx should be ignoring it... Autocxx also tries to ignore the whole type, which seems reasonable:
|
This should also gracefully handle other reasons for ignoring assignment operator overloads. Fixes google#923
I added #922 as a bit of a stress test.
It reports this panic...
This appears to be because the
implicit_constructorlogic has found aSpecialMemberKind::AssignmentOperatorwith no recorded parameters in theparam_detailsvariable.It's not clear to me why we're recording no parameters for this function. I'll look into it unless @bsilver8192 gets there first...
The text was updated successfully, but these errors were encountered: