After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 787692 - Don't hide a vfunc just because its invoker is marked as (skip)
Don't hide a vfunc just because its invoker is marked as (skip)
Status: RESOLVED OBSOLETE
Product: gobject-introspection
Classification: Platform
Component: g-ir-scanner
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks: 787271
 
 
Reported: 2017-09-14 18:27 UTC by Sam Thursfield
Modified: 2018-02-08 12:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Process vfunc even when its invoking function is marked as (skip) (1.72 KB, patch)
2017-09-14 18:28 UTC, Sam Thursfield
none Details | Review
Don't match vfunc with invoker method if one is marked (skip) (1.71 KB, patch)
2017-09-15 10:51 UTC, Sam Thursfield
none Details | Review

Description Sam Thursfield 2017-09-14 18:27:33 UTC
See https://bugzilla.gnome.org/show_bug.cgi?id=787271 for context.
Comment 1 Sam Thursfield 2017-09-14 18:28:03 UTC
Created attachment 359807 [details] [review]
Process vfunc even when its invoking function is marked as (skip)

This fixes a specific issue involving the Gio.ListModel interface.
The interface has a get_item() virtual function, and two methods that
can call it:

  * g_list_model_get_item() returns a gpointer and is marked as: (skip)
  * g_list_model_get_object() return a GObject and is marked as:
      (rename-to get_item)

I marked the ListModel->get_item() vfunc as returning GObject instead of
gpointer, which was needed to make the interface usable from Python[1].
The vfunc disappeared completely, because it now matched against
g_list_model_get_item() and the scanner would copy the (skip) annotation
across to the vfunc.

To avoid this happening, we should not copy annotations across from
methods that are marked as (skip).

1. https://bugzilla.gnome.org/show_bug.cgi?id=787271
Comment 2 Philip Withnall 2017-09-15 10:42:06 UTC
Review of attachment 359807 [details] [review]:

::: giscanner/maintransformer.py
@@ +1398,3 @@
                 if len(method.parameters) != len(vfunc.parameters):
                     continue
+                if method.skip:

Maybe `if method.skip != vfunc.skip` would be better? Then if they are both (skip) we continue to copy annotations across. (This is useful for analysis tools which use the GIR data, such as Tartan (https://www.freedesktop.org/software/tartan/).)
Comment 3 Sam Thursfield 2017-09-15 10:44:42 UTC
If they are both (skip) then neither will appear in the .gir file that gets generated. But I guess if something is importing 'giscanner' as library then it could be making use of the data. I'll do a new version.
Comment 4 Sam Thursfield 2017-09-15 10:51:27 UTC
Created attachment 359842 [details] [review]
Don't match vfunc with invoker method if one is marked (skip)

This fixes a specific issue involving the Gio.ListModel interface.
The interface has a get_item() virtual function, and two methods that
can call it:

  * g_list_model_get_item() returns a gpointer and is marked as: (skip)
  * g_list_model_get_object() return a GObject and is marked as:
      (rename-to get_item)

I marked the ListModel->get_item() vfunc as returning GObject instead of
gpointer, which was needed to make the interface usable from Python.
The vfunc disappeared completely, because it now matched against
g_list_model_get_item() and the scanner would copy the (skip) annotation
across to the vfunc.

To avoid this happening, we should not copy annotations across from
methods that are marked as (skip) to vfuncs that are not marked (skip).
Comment 5 GNOME Infrastructure Team 2018-02-08 12:48:06 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/183.