Re: HELP: fixing nullable annotations for return values

2015-08-17 Thread Philip Withnall
Hey,

On Fri, 2015-08-14 at 17:13 +0100, Alberto Ruiz wrote:
 During GUADEC I decided to revive a small effort I took a while ago. 
 I wrote a script using the private GObject Introspection AST API to 
 check if %NULL was mentioned in the documentation string of any 
 return value in any way that indicated that such function/method was 
 likely to miss the (nullable) introspection annotation.

Sorry to have missed this at GUADEC. :-(

I have a couple of bug reports open about incorrect annotations
already:
 • https://bugzilla.gnome.org/show_bug.cgi?id=742903
 • https://bugzilla.gnome.org/show_bug.cgi?id=719966

#719966 is a big one and is worth looking at because it depends on 
https://bugzilla.gnome.org/show_bug.cgi?id=729660 which suggests fixing
things by changing some of the GIR default assumptions about what’s
nullable and what’s not (regarding closures).

 I came up with a list of 143 functions that I'm trying to fix on a 
 branch (wip/aruiz/nullable-annotations), the plan is to collect and 
 review all the fixes there and then rebase/sqash into master 
 eventually. I'm tracking the effort on bgo#753520 [0] and using this 
 Google Spreadsheet[1].
 
 Anyone interested in helping fixing any of the listed functions, just 
 add your IRC nickname in the owner list in the spreadsheet[1] and 
 push into that branch. I only ask of a few things before pushing:
 - Check if (transfer none/full) applies
 - Rename NULL or #NULL as %NULL if you have the chance.
 - Check if the function is actually nullable, my script may be 
 mislead by whatever is in the document.
 
 If we have any clang hacker, it'll be great if we could tool this 
 into the compiler to check at compile time if a given function can 
 return NULL at some point. To have something like this integrated in 
 Builder and gobject introspection would certainly prevent new APIs to 
 suffer from this problem.

https://people.collabora.com/~pwith/tartan/

If I ever get time to finish it. It can already do a lot of this —
that’s how I found all the problems in bug #719966. Help very much
welcome.

Philip

signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


HELP: fixing nullable annotations for return values

2015-08-14 Thread Alberto Ruiz
Hello Gtk hackers,

During GUADEC I decided to revive a small effort I took a while ago. I
wrote a script using the private GObject Introspection AST API to check if
%NULL was mentioned in the documentation string of any return value in any
way that indicated that such function/method was likely to miss the
(nullable) introspection annotation.

I came up with a list of 143 functions that I'm trying to fix on a branch
(wip/aruiz/nullable-annotations), the plan is to collect and review all the
fixes there and then rebase/sqash into master eventually. I'm tracking the
effort on bgo#753520 [0] and using this Google Spreadsheet[1].

Anyone interested in helping fixing any of the listed functions, just add
your IRC nickname in the owner list in the spreadsheet[1] and push into
that branch. I only ask of a few things before pushing:
- Check if (transfer none/full) applies
- Rename NULL or #NULL as %NULL if you have the chance.
- Check if the function is actually nullable, my script may be mislead by
whatever is in the document.

If we have any clang hacker, it'll be great if we could tool this into the
compiler to check at compile time if a given function can return NULL at
some point. To have something like this integrated in Builder and gobject
introspection would certainly prevent new APIs to suffer from this problem.

Any further feedback or help with this effort in other libraries would be
greatly appreciated.

[0] https://bugzilla.gnome.org/show_bug.cgi?id=753520
[1]
https://docs.google.com/spreadsheets/d/1okGq07H4NnOqdCRN0KV3QduOQ6zsiomFmqK0pqYNNpo/edit#gid=141782806

-- 
Cheers,
Alberto Ruiz
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list