Commit Graph

1011 Commits

Author SHA1 Message Date
Matthias Clasen
afe30b2884 Fix a compiler warning 2012-03-05 07:54:47 -05:00
Matthias Clasen
dea3619367 gobject: Fix symbol lists 2012-03-05 07:34:58 -05:00
Alexander Larsson
f3fb42cfaf Merge branch 'signal-performance' 2012-03-05 12:29:45 +01:00
Matthias Clasen
1426a8ca07 Fix binding properties of the same object
This problem was pointed out in bug 639873.
The patch here is based on Matt Barnes patch,
I've added a testcase as well.
2012-03-04 20:49:04 -05:00
Alexander Larsson
2d6502f67b fastpath: Do allow NO_RECURSE fastpath for NOP emissions
This fixes a performance regression wrt the old NOP emission
handler.
2012-03-03 21:36:10 +01:00
Alexander Larsson
b05ea89d0c Mask out G_SIGNAL_TYPE_STATIC_SCOPE when comparing types 2012-03-02 20:22:29 +01:00
Emmanuele Bassi
d10f79a196 build: Fix rules for marshalers.[ch] 2012-03-02 17:06:36 +00:00
Alexander Larsson
3d52ee999a Add more tests for signal emissions 2012-03-02 17:13:04 +01:00
Alexander Larsson
f02ec2f2de Optimize single-handler va_marshaller case
When there is only one closure handling a signal emission and
it doesn't have a bunch of complicated features enabled we
can short circuit the va_args collection into GValues and call the
callback via the va_marshaller directly.

https://bugzilla.gnome.org/show_bug.cgi?id=661140
2012-03-02 17:13:03 +01:00
Alexander Larsson
a3e91088ce Use builtin marshallers and va_marshallers if possible
If the signal argumment types matches a built in standard
marshaller we use the va_marshaller for that, and also the
normal marshaller if NULL was specified (as its faster than
the generic one).
2012-03-02 17:13:03 +01:00
Alexander Larsson
7964cda8e6 Add g_signal_set_va_marshaller
This lets you set a va_marshaller on your signal which will be
propagated to all closures for the signal. Also, automatically
uses the generica va_marshaller if you specify a NULL c_marshaller.

https://bugzilla.gnome.org/show_bug.cgi?id=661140
2012-03-02 17:13:03 +01:00
Alexander Larsson
1c4f0ca483 Add _g_closure_is_void to check for NULL vfuncs
https://bugzilla.gnome.org/show_bug.cgi?id=661140
2012-03-02 17:13:03 +01:00
Alexander Larsson
57051905f9 Support generating va marshallers in glib-genmarshal
https://bugzilla.gnome.org/show_bug.cgi?id=661140
2012-03-02 17:13:03 +01:00
Alexander Larsson
588af03a28 Add optional support for varargs marshallers to GClosure
These closures support being invoked on a va_args which can
be useful as you can then avoid boxing the va_args into
GValues in certain cases.

https://bugzilla.gnome.org/show_bug.cgi?id=661140
2012-03-02 17:13:03 +01:00
Alexander Larsson
d5fbbe400a Add GRealClosure and move meta_marshallers there
This means we're not abusing the notifiers for meta_marshallres,
and we're able to later cleanly add other fields to GClosure.

We still have to leave the ABI intact for the GClosure->meta_marshal
bit, as old G_CLOSURE_N_NOTIFIERS macro instances still accesses it.
However, we always set it to zero to keep those macros working.

https://bugzilla.gnome.org/show_bug.cgi?id=661140
2012-03-02 17:13:03 +01:00
Christian Dywan
cb0566eaf3 gobject/gtype.c: Emphasize use of priv in member and use g_return_val_if_fail
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=597785

Signed-off-by: Javier Jardón <jjardon@gnome.org>
2012-03-01 21:40:35 +00:00
Emmanuele Bassi
ede8707129 Version the deprecation of g_value_array_get_type()
Just like the rest of the GValueArray API.
2012-02-29 17:56:06 +00:00
Emmanuele Bassi
817d992abc value array: Annotate with versioned deprecation
https://bugzilla.gnome.org/show_bug.cgi?id=670542
2012-02-27 00:00:05 -05:00
Christian Persch
d70634526d regex: Remove --disable-regex option
https://bugzilla.gnome.org/show_bug.cgi?id=622149
2012-02-26 22:22:56 -05:00
David King
500aafd099 docs: Clarify g_type_register_fundamental() behaviour
https://bugzilla.gnome.org/show_bug.cgi?id=580873
2012-02-26 22:21:19 -05:00
Rui Matos
9ff09f34cf gvaluetransform: Fix an infinite loop with GFlagsValue sets with the 0 value
Transforming a GValue holding flags from a GFlagsValue set that includes the 0
value (no flag bits set) into a string would loop until exhausting all the
available memory.

https://bugzilla.gnome.org/show_bug.cgi?id=670557
2012-02-22 12:17:38 +01:00
Dan Winship
ca05902a58 Add G_GNUC_BEGIN/END_IGNORE_DEPRECATIONS
Add new macros to disable -Wdeprecated-declarations around a piece of
code, using the C99 (and GNU89) _Pragma() operator. Replace the
existing use of #pragma for this in gio, and suppress the warnings in
gvaluearray.c as well.

https://bugzilla.gnome.org/show_bug.cgi?id=669671
2012-02-15 09:54:38 -05:00
Dan Winship
ab59739e11 gobject: Use a destructor rather than g_atexit() for refcount debugging
https://bugzilla.gnome.org/show_bug.cgi?id=669671
2012-02-15 09:54:38 -05:00
Dan Winship
f049262a61 glib-mkenums: fix handling of forward enum declarations
Given

    typedef enum MyFoo MyFoo;

glib-mkenums would get confused, not notice the ";", and then keep
skipping lines until it found one that started with a "{", possibly
even going into the next file.

Fix it to just ignore those lines instead (and also, to error out if
it hits eof while parsing an enum).

https://bugzilla.gnome.org/show_bug.cgi?id=669595
2012-02-07 13:32:22 -05:00
Matthias Clasen
9ffc3391ed Fix doc syntax 2012-01-30 15:37:28 -05:00
Matthias Clasen
b01af10c86 Remove a check that triggers deprecation warnings 2012-01-30 14:06:22 -05:00
Emmanuele Bassi
0ac9ab4e27 Deprecate GValueArray
The GValueArray type was added in a time, during the Jurassic era or so,
when GArray did not have a representable GType. The GValueArray API has
various issues as well:

  - it doesn't match the other GLib array types;
  - it is not reference counted;
  - the structure is fully exposed on the stack, so it cannot be
    extended to add reference counting;
  - it cannot be forcibly resized.

The nice thing is that now we have a GArray type that can replace in
full GValueArray, so we can deprecate the latter, and reduce the
complexity in GLib, application code, and bindings.

https://bugzilla.gnome.org/show_bug.cgi?id=667228
2012-01-24 23:37:24 -05:00
Ryan Lortie
cf48434867 gsignal: add g_signal_handlers_disconnect_by_data
Similar to g_signal_handlers_disconnect_by_func() but disconnects all
functions that use the given user_data.

https://bugzilla.gnome.org/show_bug.cgi?id=668269
2012-01-19 10:49:31 -05:00
Benjamin Otte
9d52243790 values: Use v_pointer for g_value_set_gtype()
... and g_value_get_gtype(). G_TYPE_GTYPE is a pointer type, so it's
values should use the v_pointer member. This is especially true, because
the value collectors from varargs in gvaluecollector.h use that, too.

This should only cause issues when sizeof(glong) != sizeof(gpointer),
and I'm not aware of any such platform. Maybe win64?
2012-01-14 01:15:16 +01:00
Simon McVittie
254efaf85e Skip tests of incorrect property usage under gtester -m no-undefined
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666116
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
2012-01-05 15:47:26 +00:00
Matthias Clasen
99c166501a Fix parameter name mismatches in GWeakRef api 2012-01-03 10:48:50 -05:00
Simon McVittie
146aa7aa17 Add regression test for GWeakRef used to cache a singleton
https://bugzilla.gnome.org/show_bug.cgi?id=548954
2012-01-02 12:23:21 -05:00
Simon McVittie
fa5ff39559 Add deterministic tests for the API of GWeakRef
These don't address the thread-safety, but do address basic use.

https://bugzilla.gnome.org/show_bug.cgi?id=548954
2012-01-02 12:23:18 -05:00
Ryan Lortie
46c2f570da GWeakRef: add a weak GObject reference believed to be thread-safe
This patch is a joint work with Simon McVittie.

https://bugzilla.gnome.org/show_bug.cgi?id=548954
2012-01-02 12:23:15 -05:00
Simon McVittie
28c87a5594 g_object_weak_ref, g_object_add_weak_pointer: document non-thread-safety
Transparent access to a weak pointer from the thread performing the
weak -> strong conversion is incompatible with thread-safety: that
thread will have to do something special. This is GNOME#548954.

https://bugzilla.gnome.org/show_bug.cgi?id=548954
2012-01-02 12:23:11 -05:00
Simon McVittie
fa4792c35e various tests: do not provoke SIGTRAP with -m no-undefined
Some of the GLib tests deliberately provoke warnings (or even fatal
errors) in a forked child. Normally, this is fine, but under valgrind
it's somewhat undesirable. We do want to follow fork(), so we can check
for leaks in child processes that exit gracefully; but we don't want to
be told about "leaks" in processes that are crashing, because there'd
be no point in cleaning those up anyway.

https://bugzilla.gnome.org/show_bug.cgi?id=666116
2011-12-27 17:51:09 -05:00
Ryan Lortie
557da16507 GObject: do checks on interface property install
Add some checks to g_object_interface_install_property() similar to
those in g_object_class_install_property().

https://bugzilla.gnome.org/show_bug.cgi?id=666616
2011-12-20 19:45:57 -05:00
Ryan Lortie
b237187109 GObject: require READ or WRITE on property install
g_object_class_install_property() currently lets you install properties
that are neither readable nor writable.  Add a check to prevent that.

https://bugzilla.gnome.org/show_bug.cgi?id=666616
2011-12-20 19:43:21 -05:00
Ryan Lortie
4e793c2eef GObject: allow G_PARAM_CONSTRUCT on any override
We were previously preventing implementations of an interface from
specifying G_PARAM_CONSTRUCT for a property of that interface if the
interface didn't specify it itself (or was readonly).

This is something that should only interest the implementation, so we
remove this restriction.

This allows 6 new possible override scenarios:

 - writable                 -> writable/construct
 - writable                 -> readwrite/construct
 - readwrite                -> readwrite/construct
 - writable/construct-only  -> writable/construct
 - writable/construct-only  -> readwrite/construct
 - readwrite/construct-only -> readwrite/construct

and we update the testcase to reflect this.

https://bugzilla.gnome.org/show_bug.cgi?id=666616
2011-12-20 19:40:44 -05:00
Ryan Lortie
b3b9f82206 GObject: add test for interface property overrides
Add a testcase to check all possibilities for overriding a property
specified on an interface from an implementation of that interface,
changing the type and flags.

https://bugzilla.gnome.org/show_bug.cgi?id=666616
2011-12-20 19:18:26 -05:00
Ryan Lortie
d8d78688a8 GObject: change the order of property checks
Change the order of the checks so that we hear about the 'biggest'
problem first.  Also, stop reporting problems after we report the first
one for a particular property.

Add some comments.

https://bugzilla.gnome.org/show_bug.cgi?id=666616
2011-12-20 19:18:25 -05:00
Ryan Lortie
5fb7a8e127 GObject: fix property override type checks
The property override typecheck was meant to enforce the type on the
overriding property being exactly equal to the type on the interface
property.  Instead, g_type_is_a() was incorrectly used.

We could try to enforce equality, but if a property is read-only then it
should be possible for the implementation to type the property with any
subtype of the type specified on the interface (because returning a more
specific type will still satisfy the interface).  Likewise, if the
property is write-only then it should be possible for the implementation
to type the property with any supertype.

We implement the check this way.

https://bugzilla.gnome.org/show_bug.cgi?id=666616
2011-12-20 19:18:25 -05:00
Ryan Lortie
958f2bac7a GObject: fixup reversed logic in last commit
Accidentally dropped a !.
2011-12-20 15:29:16 -05:00
Ryan Lortie
3af050f6fc gobject: Clean up logic in property checks
Simplify some of the logic in this function.

  1) Simplify flag checks as per Colin's suggestions in
     https://bugzilla.gnome.org/show_bug.cgi?id=605667

  2) Don't repeatedly recheck if class_pspec is NULL.
2011-12-20 15:12:44 -05:00
Ryan Lortie
af24dbc12a gobject: loosen property override flag restrictions
GObject enforces the following restrictions on property overrides:

  - must only add abilities: if the parent class supports
    readability/writability then the subclass must also support them.
    Subclasses are free to add readability/writability.

  - must not add additional restrictions: if the parent class doesn't
    have construct/construct-only restrictions then the subclass must
    not add them.  Subclasses are free to remove restrictions.

The problem with the previous implementation is that the check against
adding construct/construct-only restrictions was being done even if the
property was not previously writable.  As an example:

  "readable" and "writable only on construct"

was considered as being more restrictive than

  "read only".

This patch tweaks the check to allow the addition of
construct/construct-only restrictions for properties that were
previously read-only and are now being made writable.

https://bugzilla.gnome.org/show_bug.cgi?id=666615
2011-12-20 14:58:38 -05:00
Ryan Lortie
a2e9318d4a two test fixes for ARM
First, some ARM systems are not fast enough to meet the 30 second
deadline in gwakeuptest.c, so increase that to 60.

Second, we have some signed/unsigned woes in the gparam transform tests.
2011-12-14 09:33:30 -05:00
Simon McVittie
29f2ced8eb various GLib tests: plug memory leaks
These don't really matter, since it's test code, but they do obscure
real leaks in the library.

Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666115
Acked-by: Matthias Clasen <mclasen@redhat.com>
2011-12-14 12:40:16 +00:00
Stef Walter
7e92997539 documentation fixes
Fixes for gtk-doc warnings.

http://bugzilla.gnome.org/show_bug.cgi?id=66469

https://bugzilla.gnome.org/show_bug.cgi?id=664699
2011-12-13 23:01:51 -05:00
Matthias Clasen
e50d8a11b2 Cosmetic doc change 2011-12-09 08:01:12 -05:00
Nicola Fontana
f24d8247b3 Do not use static GTypeInfo and GInterfaceInfo
Either g_type_register_static_simple (used by G_DEFINE_TYPE_EXTENDED)
and G_IMPLEMENT_INTERFACE use automatic variables for GTypeInfo and
GInterfaceInfo structs, while tutorials and source code often use
static variables. This commit consistently adopts the former method.

https://bugzilla.gnome.org/show_bug.cgi?id=600161
2011-11-29 22:03:25 -05:00