GNOME Bugzilla – Bug 676815
scanner: Add a way to mark a function not-a-constructor
Last modified: 2015-02-07 16:51:10 UTC
Trying to kill of spurious scanner warnings in libsoup. Not totally sure about the syntax... (I actually only need (constructor false), but (method false) was easy to implement as well while I was there...)
Created attachment 214938 [details] [review] scanner: Add (constructor false) and (method false) annotations Add (constructor false) and (method false) annotations, to override the scanner's default assumption that a particular function is a constructor/method. Eg, (constructor false) can be used on a function with "_new" in its name to avoid getting a warning about not being able to match it up with a type.
Review of attachment 214938 [details] [review]: Why not say what it is, rather than what it isn't? Why don't the existing (method) annotations work for this? ::: giscanner/maintransformer.py @@ +1152,3 @@ + # func.is_constructor will be True if we have a (constructor) + # or (constructor true) annotation, False if (constructor false), + # and None otherwise Urg...turning them into a tristate internally is ugly.
(In reply to comment #2) > Why not say what it is, rather than what it isn't? Why don't the existing > (method) annotations work for this? Because they aren't methods either. They're just functions that have "_new" in their name, so the scanner wants them to be constructors, and then complains that it can't figure out what they're constructors for. I guess I could just add a (function) annotation instead... that would solve the tristate problem too.
Created attachment 215085 [details] [review] scanner: allow for functions that look like constructors but aren't If the scanner found a function with _new in its name, but not prefixed by the name of a known type, it would assume that the function was a constructor, and then complain that it couldn't figure out what it was a constructor for, and mark it introspectable=0. Instead, just assume that the function is not actually a constructor in that case (unless it's explicitly tagged as such). === Forget all the stuff before, this is what we should be doing. Note that this behavior ("error if the function is explicitly tagged a constructor, silently assume it's not a constructor otherwise") matches the scanner's existing behavior for a function that has "new" in its name but returns an unrelated type.
Review of attachment 215085 [details] [review]: This makes sense now that we can explicitly tag methods as constructors.
Attachment 215085 [details] pushed as 44cf78b - scanner: allow for functions that look like constructors but aren't
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]