This is for destroying resources needed by transformations. But the user
may not need any such resources. Make it obvious that, instead of having
to point to a no-op function, @notify is checked and not called if NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=792098
Weak-pointers are currently lacking g_set_object() & g_clear_object()
helpers equivalent. New functions (and macros, both are provided) are
convenient in many case, especially for the property's notify-on-set
pattern:
if (g_set_weak_pointer (...))
g_object_notify (...)
Inspired by Christian Hergert's original implementation for
gnome-builder.
https://bugzilla.gnome.org/show_bug.cgi?id=749527
Conceptually, these functions clearly ought to be fine for a const
structure. This avoids _G_TYPE_CVH (the implementation of
G_TYPE_CHECK_VALUE_TYPE, G_VALUE_HOLDS, G_VALUE_HOLDS_BOXED etc.)
needing to cast to a mutable GValue, which causes
G_VALUE_HOLDS (cv, type) to issue warnings under gcc -Wcast-qual if
cv is a const GValue *.
https://bugzilla.gnome.org/show_bug.cgi?id=734479
Some source files aren't valid utf-8 containing for example
iso8859-1 accented characters in author's names.
Replace invalid data with a replacement '?' character and print a
warning to keep things working.
Based on a patch from Christoph Reiter in
https://bugzilla.gnome.org/show_bug.cgi?id=785113#c20
The type propagation breaks the GRefPtr.h class in WebKitGTK, and in
any case existing C++ code calling the C API will need to perform an
explicit cast, as there's no automatic promotion of pointer types to
and from void*.
Tested-by: GNOME Continuous
https://bugzilla.gnome.org/show_bug.cgi?id=790697
When compiling code that includes gobject.h using GCC with the ISO
standard, the `typeof` keyword is disabled, as it's a GCC extension.
The GCC documentation recommends:
> If you are writing a header file that must work when included in
> ISO C programs, write __typeof__ instead of typeof.
Which is precisely what we're going to do.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790697
Currently, g_object_ref() and g_object_ref_sink() return a
gpointer which can mask issues when assigning to fields or
returning from a function.
To help catch these type of programming errors, we can propagate
the type of the parameter through the function call on GCC
using the typeof() C language extension.
This will cause offending code to have a warning, but will
continue to be source and binary compatible.
This is only enabled when GLIB_VERSION_MAX_ALLOWED is 2.56 or greater.
https://bugzilla.gnome.org/show_bug.cgi?id=790697
Putting a <!-- --> in plural<!-- -->s was an old hack used to fix
linking the symbol with gtk-doc when gtk-doc didn’t know about plural
forms. gtk-doc does now know about plural forms, so the hack can be
removed.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It's theoretically possible that we could have a case where this would
actually return NULL, but it's difficult to imagine a valid program that
would contain such a case.
Add an explicit assert here to quiet up static analysis.
See the bug for more discussion.
Coverity CID: 1159477
https://bugzilla.gnome.org/show_bug.cgi?id=730296
Where we were already treating GHashTables as sets, modify them to use
the set-specific APIs g_hash_table_add() and g_hash_table_contains(), to
make that usage more obvious and less prone to being broken.
Heavily based on patches by Garrett Regier <garrettregier@gmail.com>.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=749371
Clarify the licensing of the code generated by the two scripts in a
comment in the header of each generated file. The intention is that the
license of GLib does *not* apply to the generated files; but that they
are subject to the linking restrictions of the LGPL, since they link to
GLib and GLib is licensed under the LGPL. The generated files themselves
are under the license of whatever project they’re generated for.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788990
We should ensure a stable order when processing the files, regardless of
the order they were submitted on the command line, to increase the
chances of a reproducible build.
The old Perl-based version of glib-mkenums was fixed in commit 8686e430
to do the same.
https://bugzilla.gnome.org/show_bug.cgi?id=691436
The fallback code for providing a default comment template only worked
if a template file was provided. It didn’t work if individual templates
were provided on the command line (and --comment wasn’t).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788990
They return floating references. The convention established by GVariant
is to annotate these as (transfer none) so that the caller does a
ref+sink on them, rather than just a ref.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=677233
The m4 and bash completion items are usable and relevant
depending on the host system's configuration. So, we check for the
presence of the programs that these items depend on, and only install
them when those programs are found.
For the Valgrind suppression files, we don't install them on Windows as
Valgrind is currently not supported on Windows.
Als fix the path where the GDB helpers are installed, as the path is
incorrectly constructed.
This will fix the "install" stage when building on Visual Studio at
least as there are some post-install steps that are related to them,
which will make use of these programs.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
This was duplicated also in g_object_interface_install_property().
Now, validations specific to classes happen in
validate_and_install_class_property() - specifically, the checks for
the presence of the get_property() and set_property() methods.
https://bugzilla.gnome.org/show_bug.cgi?id=787551
Commit 31ae2c5598 added the C++ guards
around all prototypes, including inside the header file. The header
file, though, already has C++ guards, so while it's harmless to have
them there, it's also unnecessary.
We should only emit C++ guards around the prototypes we include in the
generated source.
Since --header --body has been deprecated and replaced with --body
--prototypes, the generated body is not wrapped with G_{BEGIN,END}_DECLS
any longer. Projects using C++ break due to that. Automatically wrap
prototypes individually in G_{BEGIN,END}_DECLS instead.
https://bugzilla.gnome.org/show_bug.cgi?id=785554
In case of Python 2 and stdout being redirected to a file, sys.stdout.encoding
is None and it defaults ASCII for encoding text.
To match the behaviour of Python 3, which uses the locale encoding also when
redirecting to a file, wrap sys.stdout with a StreamWriter using the
locale encoding.
https://bugzilla.gnome.org/show_bug.cgi?id=785113
Instead of using NamedTemporaryFile, which doesn't take an encoding in Python 2
use mkstemp() to create a file and open it with io.open(), with a proper
encoding set.
https://bugzilla.gnome.org/show_bug.cgi?id=785113
On Windows open() defaults to ANSI and on Python 2 it doesn't take
an encoding. Use io.open() instead which provides the same interface
on both Python versions.
https://bugzilla.gnome.org/show_bug.cgi?id=785113
