un-copyable struct fields generated with #[derive(Copy)]

BrainBlasted commented 5 years ago

Similar to #534, I'm running into structs that #[derive(Copy)] but are un-copyable, this time because of a generated _trucated_record_marker, causing the build to fail.

Log:

error[E0204]: the trait `Copy` may not be implemented for this type
    --> libdazzle-sys/src/lib.rs:1186:10
     |
1186 | #[derive(Copy, Clone)]
     |          ^^^^
...
1201 |     _truncated_record_marker: c_void,
     |     -------------------------------- this field does not implement `Copy`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0204`.
error: Could not compile `libdazzle-sys`.

Struct:

#[repr(C)]
#[derive(Copy, Clone)]
pub struct DzlPreferencesInterface {
    pub parent_interface: gobject::GTypeInterface,
    pub set_page: Option<unsafe extern "C" fn(*mut DzlPreferences, *const c_char, *mut glib::GHashTable)>,
    pub add_page: Option<unsafe extern "C" fn(*mut DzlPreferences, *const c_char, *const c_char, c_int)>,
    pub add_group: Option<unsafe extern "C" fn(*mut DzlPreferences, *const c_char, *const c_char, *const c_char, c_int)>,
    pub add_list_group: Option<unsafe extern "C" fn(*mut DzlPreferences, *const c_char, *const c_char, *const c_char, gtk::GtkSelectionMode, c_int)>,
    pub add_radio: Option<unsafe extern "C" fn(*mut DzlPreferences, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, c_int) -> c_uint>,
    pub add_font_button: Option<unsafe extern "C" fn(*mut DzlPreferences, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, c_int) -> c_uint>,
    pub add_switch: Option<unsafe extern "C" fn(*mut DzlPreferences, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, c_int) -> c_uint>,
    pub add_spin_button: Option<unsafe extern "C" fn(*mut DzlPreferences, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, c_int) -> c_uint>,
    pub add_file_chooser: Option<unsafe extern "C" fn(*mut DzlPreferences, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, *const c_char, gtk::GtkFileChooserAction, *const c_char, c_int) -> c_uint>,
    pub add_custom: Option<unsafe extern "C" fn(*mut DzlPreferences, *const c_char, *const c_char, *mut gtk::GtkWidget, *const c_char, c_int) -> c_uint>,
    pub remove_id: Option<unsafe extern "C" fn(*mut DzlPreferences, c_uint) -> gboolean>,
    pub get_widget: Option<unsafe extern "C" fn(*mut DzlPreferences, c_uint) -> *mut gtk::GtkWidget>,
    _truncated_record_marker: c_void,
    // /*Unimplemented*/Option<unsafe extern "C" fn(*mut DzlPreferences, *const c_char, *const c_char, *mut gtk::GtkWidget, /*Unimplemented*/va_list) -> c_uint>
}

BrainBlasted commented 5 years ago

This is the function that's failing to generate:

guint
dzl_preferences_add_table_row (DzlPreferences *self,
                               const gchar    *page_name,
                               const gchar    *group_name,
                               GtkWidget      *first_widget,
                               ...)
{
  va_list args;
  gint ret;

  g_return_val_if_fail (DZL_IS_PREFERENCES (self), 0);
  g_return_val_if_fail (page_name != NULL, 0);
  g_return_val_if_fail (group_name != NULL, 0);
  g_return_val_if_fail (GTK_IS_WIDGET (first_widget), 0);

  va_start (args, first_widget);
  ret = DZL_PREFERENCES_GET_IFACE (self)->add_table_row_va (self, page_name, group_name, first_widget, args);
  va_end (args);

  return ret;
}

Here's the header file and .c file

sdroege commented 5 years ago

This looks like a bug in gir, or the .gir file is broken. Can you attach the .gir file or paste the relevant part (the struct definition of DzlPreferencesInterface) here?

There's no reason for creating a truncated version of the struct here. It's all pointers, and varargs C functions can be properly expressed in Rust too (you can even call them, just not yet define new ones).

sdroege commented 5 years ago

CC @EPashkin Or maybe you already have an idea about this one?