Generated .gir data contains incomplete type definitions

[Martin Blanchard]

Experienced behavior

Generating .gir data produces incomplete field type declaration:

      <field name="value" introspectable="0" readable="0" private="1">
        <type c:type="graphene_simd4f_t"/>
      </field>

      <field name="value" introspectable="0" readable="0" private="1">
        <type c:type="graphene_simd4x4f_t"/>
      </field>

Expected behavior

Every (required) type are properly detected and generated Graphene-1.0.gir does not contain incomplete type elements.

Steps to reproduce

Building from sources using meson generates Graphene-1.0.gir.

Operating system in use

JHBuild environment on Fedora 29.

SIMD implementation in use

Irrelevant.

[Martin Blanchard]

The two problematic types, graphene_simd4f_t and graphene_simd4x4f_t are not part of the public API but only reported because they are private members of public type structures declared in public headers.

Might a solution be to change the GRAPHENE_PRIVATE_FIELD() macro so that it hides private members when __GI_SCANNER__ is defined?

[Emmanuele Bassi]

The SIMD types are part of the public C API, but they are not part of the introspectable API because:

• they have different implementations, depending on the platform and on the build options of Graphene
• outside of C, they make no sense without a proper wrapper

Additionally, the sizing information only makes sense if you're trying to allocate any wrapper type manually, which is not the intended behaviour; Graphene provides allocator functions for that exact reason.

From an introspection perspective, I could probably make graphene_simd4f_t the equivalent of sizeof(float) * 4 and graphene_simd4x4f_t the equivalent of sizeof(float) * 16, but the intended behaviour of the API would exactly be the same: always use the allocator and deallocator functions provided by Graphene, and never attempt to allocate and free Graphene types using your own allocator functions.

[Martin Blanchard]

Thanks for the clarifications!

From an introspection perspective, I could probably make graphene_simd4f_t the equivalent of sizeof(float) * 4 and graphene_simd4x4f_t the equivalent of sizeof(float) * 16, but the intended behaviour of the API would exactly be the same: always use the allocator and deallocator functions provided by Graphene, and never attempt to allocate and free Graphene types using your own allocator functions.

Correct me if I'm wrong, but private field names of public API C types are mangled when used outside of graphene itself, right? Then why not simply hide them completely in the introspection API? Wouldn't that avoid the need of handling this kind of equivalence?

[Emmanuele Bassi]

Then why not simply hide them completely in the introspection API? Wouldn't that avoid the need of handling this kind of equivalence?

gobject-introspection cannot "hide" public fields in introspected structures: even private fields need to be appropriately added to the introspection data, even if they cannot be accessed.

All the fields inside Graphene public structures are already marked as private, including the ones that are not introspectable; this means that the field is there because it contributes to the size of the structure, but cannot be accessed, and should not be visible when using the structure.