GNOME Bugzilla – Bug 629682
support typedefs for container types
Last modified: 2018-02-08 11:59:36 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)
We also need a workaround for libgda, see bug 629779.
(and in case you hadn't seen, we need a workaround for gnome-keyring, see patch in bug 629426)
Patch for libgda attached to bug 629779.
(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 ;-)
I'm hitting this in rhythmbox too, using GPtrArray, in case that's of any interest to anyone.
*** Bug 630935 has been marked as a duplicate of this bug. ***
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.
*** Bug 634307 has been marked as a duplicate of this bug. ***
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."""
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?
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.
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.
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.
pushed as commit 24a5ba0.
*** Bug 637177 has been marked as a duplicate of this bug. ***
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.
*** Bug 629426 has been marked as a duplicate of this bug. ***
Is this fixed?
(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.
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
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…
-- 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.