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 629682 - support typedefs for container types
support typedefs for container types
Status: RESOLVED OBSOLETE
Product: gobject-introspection
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
: 629426 630935 634307 637177 (view as bug list)
Depends on:
Blocks: 625942 629779
 
 
Reported: 2010-09-14 16:54 UTC by Colin Walters
Modified: 2018-02-08 11:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
only write basic type information inside aliases (4.37 KB, patch)
2010-10-27 09:39 UTC, Jonathan Matthew
reviewed Details | Review
check aliases in introspectablepass (7.90 KB, patch)
2010-12-04 02:17 UTC, Jonathan Matthew
committed Details | Review

Description Colin Walters 2010-09-14 16:54:45 UTC
Various libraries have used the pattern:

/**
 * FooAttributeSet: (element-type utf8)
 *
 */
typedef GList FooAttributeSet;

Right now we have a hack for Atk; we could either:

1) Generically unwind the typedef inside the compiler, marking it introspectable=0.  This pretty much disallows scanning libraries that do this.
2) Support it.  (Probably not too hard)
Comment 1 Vincent Untz 2010-09-18 16:35:04 UTC
We also need a workaround for libgda, see bug 629779.
Comment 2 Vincent Untz 2010-09-18 16:54:29 UTC
(and in case you hadn't seen, we need a workaround for gnome-keyring, see patch in bug 629426)
Comment 3 Vincent Untz 2010-09-18 17:53:04 UTC
Patch for libgda attached to bug 629779.
Comment 4 Vincent Untz 2010-09-18 17:53:59 UTC
(In reply to comment #3)
> Patch for libgda attached to bug 629779.

I mean: patch adding a workaround for libgda in gobject-introspection.

Clearly, you want one of the two solutions you highlighted above since adding workaround just won't work in the long term ;-)
Comment 5 Jonathan Matthew 2010-09-22 13:13:45 UTC
I'm hitting this in rhythmbox too, using GPtrArray, in case that's of any interest to anyone.
Comment 6 Colin Walters 2010-10-05 15:56:18 UTC
*** Bug 630935 has been marked as a duplicate of this bug. ***
Comment 7 Jonathan Matthew 2010-10-27 09:39:14 UTC
Created attachment 173310 [details] [review]
only write basic type information inside aliases

As far as I can tell, the first pass in girepository/girparser.c is only interested in finding the name attribute of a type tag inside the alias tag, so the scanner shouldn't write the full type of the alias target.  This fixes at least atk, gnome-keyring, and my problem, and doesn't result in any changes to any other girs I can see.
Comment 8 Colin Walters 2010-11-15 16:33:36 UTC
*** Bug 634307 has been marked as a duplicate of this bug. ***
Comment 9 Colin Walters 2010-12-02 22:30:34 UTC
Review of attachment 173310 [details] [review]:

So, this patch will stop us from crashing obviously, but there are issues.  For example I'm not sure what the introspectablepass.py will do with aliases (checks).  Looks like these methods will be marked as not-introspectable since we don't have any handling for Alias nodes there.

Is that OK for what you're using?  You just want the scanner to not crash?

::: giscanner/girwriter.py
@@ +242,3 @@
         return typeval.target_giname
 
+    def _write_type_ref(self, ntype):

I know most of the functions aren't documented, but this one could use a comment/docstring for why it's different from _write_type.  Say:

"""Like _write_type, but only write the base type for container types."""
Comment 10 Jonathan Matthew 2010-12-02 23:02:09 UTC
My immediate goal is to get from 'introspection doesn't work' to 'introspection kinda works', but since I'm likely to run into deeper problems here, I might as well try to fix some of them now.

In introspectablepass.py, it looks like we'd mostly need to look up the alias target in _introspectable_param_analysis and _type_is_introspectable, right?
Comment 11 Jonathan Matthew 2010-12-04 01:35:45 UTC
Actually it looks like we (potentially) have the opposite problem - things not being marked not-introspectable that should be.  _type_is_introspectable ends up looking at target.introspectable, which for an ast.Alias is always True, whether or not the target of the alias is introspectable.  I guess that needs to be set correctly then.
Comment 12 Jonathan Matthew 2010-12-04 02:17:29 UTC
Created attachment 175817 [details] [review]
check aliases in introspectablepass

I added the alias check as a new pass in introspectablepass.py, which possibly isn't a great idea performance wise, but I don't know how all the passes in there fit together well enough to figure out where it really belongs.
Comment 13 Colin Walters 2010-12-15 16:17:29 UTC
Review of attachment 175817 [details] [review]:

Thanks for the patch!  This is definitely an improvement.

::: giscanner/introspectablepass.py
@@ +33,2 @@
     def validate(self):
+        self._namespace.walk(self._introspectable_alias_analysis)

Hmm.  This won't correctly handle aliases to types that aren't introspectable for dynamic reasons (annotated with (skip) say), but that's OK.  Fully fixing these kinds of problems is really hard.
Comment 14 Jonathan Matthew 2010-12-15 21:46:54 UTC
pushed as commit 24a5ba0.
Comment 15 Martin Pitt 2012-11-20 06:21:41 UTC
*** Bug 637177 has been marked as a duplicate of this bug. ***
Comment 16 Colin Walters 2012-12-10 19:04:54 UTC
See https://bugzilla.gnome.org/show_bug.cgi?id=689871 for a recent example of this in evolution-data-server.

The current state of this is still pretty broken; the scanner will produce a .gir that just isn't useful, and it won't even warn you.
Comment 17 Colin Walters 2012-12-10 19:07:10 UTC
*** Bug 629426 has been marked as a duplicate of this bug. ***
Comment 18 Jasper St. Pierre (not reading bugmail) 2012-12-10 20:09:43 UTC
Is this fixed?
Comment 19 Colin Walters 2012-12-10 22:39:30 UTC
(In reply to comment #18)
> Is this fixed?

No.  It's actually really ugly to do in the scanner.  Now, we could somewhat easily detect the case where the library typedefs a container, and unwind the typedef everywhere we see it.  But library authors would still need to add element-type annotations to all functions.

But what library authors clearly want is the ability to create a typedef and have a global element-type.  The problem with doing that is the scanner would need to keep around the original alias information, but when writing out the .gir, we'd need to substitute it, since the typelib compiler wouldn't know how to handle it.

Hacking up the typelib compiler to understand the new format is possible, but more involved.
Comment 20 André Klapper 2015-02-07 17:17:13 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
Comment 21 Emmanuele Bassi (:ebassi) 2017-12-22 13:09:34 UTC
So, this is now biting us hard after landing autoptr support for lists — see bug 791342.

Since the `typedef GList* FooBar_listautoptr` line is autogenerated, we cannot have an element type annotation associated with it, because the C pre-processor won't propagate comments. If only annotations could be macros/attributes…
Comment 22 GNOME Infrastructure Team 2018-02-08 11:59:36 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/36.