Generates un-Copyable structs with #[derive(Copy)] in case of padding

[sdroege]

In GStreamer for example:

#[derive(Copy, Clone)]
pub struct GstVideoCodecState {
    pub ref_count: c_int,
    pub info: GstVideoInfo,
    pub caps: *mut gst::GstCaps,
    pub codec_data: *mut gst::GstBuffer,
    pub allocation_caps: *mut gst::GstCaps,
    pub padding: [c_void; 19],
}

leads to

error[E0204]: the trait `Copy` may not be implemented for this type
   --> gstreamer-video-sys/src/lib.rs:817:10
    |
817 | #[derive(Copy, Clone)]
    |          ^^^^
...
824 |     pub padding: [c_void; 19],
    |     ------------------------- this field does not implement `Copy`

Problem here is (AFAIU) that this is c_void, it should be *mut c_void or gpointer.

[sdroege]

@tmiasko @EPashkin Any ideas here? The field in question is

      <field name="padding" readable="0" private="1">
        <array zero-terminated="0" c:type="void" fixed-size="19">
          <type name="gpointer" c:type="void*"/>
        </array>
      </field>

In other places where it works, it is

      <field name="_gst_reserved" readable="0" private="1">
        <array zero-terminated="0" c:type="gpointer" fixed-size="3">
          <type name="gpointer" c:type="gpointer"/>
        </array>
      </field>

[sdroege]

Changing void * in the C header to gpointer would be fixing this, but that does not seem like a good solution

[sdroege]

This is the same as #478, but more severe now as things stop compiling, while before it was only a problem with the struct size.

[ghost]

Apart from the fact that this is bug in gir xml, see #478 (comment),
I think on our part, we could do better by always looking at the innermost
c:type attribute. It seems to be the most accurate. This is somewhat tricky
because in case of arrays we don't retain it after parsing.

[EPashkin]

We use field "c_type" too aggressively in sys,
Seems only way in code is check for c_type for Some("void") and change it to Some("gpointer") before https://github.com/gtk-rs/gir/blob/master/src/parser.rs#L1165
Or just do same replace for all 5 c:type="void" fixed-size= in GstVideo-1.0.gir

[EPashkin]

Inner type stored in Type::FixedArray.0 but used wrong in this case due https://github.com/gtk-rs/gir/blob/master/src/codegen/sys/ffi_type.rs#L94

[EPashkin]

Renaming also works before https://github.com/gtk-rs/gir/blob/master/src/codegen/sys/ffi_type.rs#L125,
but this will affect only sys'es

[sdroege]

Generally, the type void alone in C is invalid, except for a return type or as a pointer. So renaming all void to gpointer seems an ok workaround, but quite ugly IMHO.

OTOH it seems impossible to correctly detect the right thing from the GIR?

[EPashkin]

@sdroege So decision up to you:

1. you can fix GstVideo-1.0.gir (good that it only one with this error), with possibility report bug upstream,
2. I can update Gir with fix in parser or in sys generation, this way we also silently fix some other crates,
   but upstream still be bad.

[sdroege]

I'd vote for 1. (I can just fix it upstream anyway), and someone reports a bug against gobject-introspection?

[sdroege]

https://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=30833f6242b0480fd78a52cd8cc1169fd9b75706 FWIW

[EPashkin]

Then I close this issue

[sdroege]

You report to gobject-introspection, or @tmiasko who debugged this in detail?

[EPashkin]

I had bad experience with gnome bugzilla, so I pass

[ghost]

There is enough related bug reports in bugzilla that I don't feel that it is
necessary to report this one. See my comment referenced above.