Commit Graph

204 Commits

Author SHA1 Message Date
Thomas Haller
938a1caf89 gtype: avoid "-Wcast-align" warning with optimized G_TYPE_CHECK_INSTANCE_CAST()
We can get a "-Wcast-align", if the target type that we cast to ("ct") has a
larger alignment than GTypeInstance.

That can happen on i686 architecture, if the GObject type has larger
alignment than the parent struct (or GObject). Since on i686, embeding
a "long long" or a "long double" in a struct still does not increase
the alignment beyond 4 bytes, this usually only happens when using the
__attribute__() to increase the alignment (or to have a field that has
the alignment increased).

It can happen on x86_64 when having a "long double" field.

The compiler warning is hard to avoid but not very useful, because it purely
operates on the pointer types at compile time. G_TYPE_CHECK_INSTANCE_CAST()
instead asserts (in non-optimized mode) that the pointer really points
to the expected GTypeInstance (and if that's the case, then the alignment
should be suitable already).

This is like in commit ed553e8e30 ('gtype: Eliminate -Wcast-align warnings
with G_TYPE_CHECK_INSTANCE_CAST'). But also fix the optimized code path.

With the unpatched G_TYPE_CHECK_INSTANCE_CAST() macro, the unit test would
now show the problem (with gcc-9.3.1-2.fc30.i686 or
gcc-12.2.1-4.fc37.x86_64):

  $ export G_DISABLE_CAST_CHECKS=1
  $ export CFLAGS='-Wcast-align=strict'
  $ meson build
  $ ninja -C build
  ...
  In file included from ../gobject/gobject.h:26,
                   from ../gobject/gbinding.h:31,
                   from ../glib/glib-object.h:24,
                   from ../gobject/tests/objects-refcount1.c:2:
  ../gobject/tests/objects-refcount1.c: In function ‘my_test_dispose’:
  ../gobject/gtype.h:2523:42: warning: cast increases required alignment of target type [-Wcast-align]
   2523 | #  define _G_TYPE_CIC(ip, gt, ct)       ((ct*) ip)
        |                                          ^
  ../gobject/gtype.h:517:66: note: in expansion of macro ‘_G_TYPE_CIC’
    517 | #define G_TYPE_CHECK_INSTANCE_CAST(instance, g_type, c_type)    (_G_TYPE_CIC ((instance), (g_type), c_type))
        |                                                                  ^~~~~~~~~~~
  ../gobject/tests/objects-refcount1.c:9:37: note: in expansion of macro ‘G_TYPE_CHECK_INSTANCE_CAST’
      9 | #define MY_TEST(test)              (G_TYPE_CHECK_INSTANCE_CAST ((test), G_TYPE_TEST, GTest))
        |                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~
  ../gobject/tests/objects-refcount1.c:96:10: note: in expansion of macro ‘MY_TEST’
     96 |   test = MY_TEST (object);
        |          ^~~~~~~
2022-12-16 20:48:06 +01:00
Marco Trevisan (Treviño)
372ab7a964 glib: Use G_CXX_STD_VERSION to check how to behave with C++ compilers 2022-11-22 17:23:12 +01:00
Matthias Clasen
fd0dd9e93c gobject: Add G_TYPE_FLAG_DEPRECATED
This can be used to mark entire types as deprecated,
and trigger a warning when they are instantiated
and `G_ENABLE_DIAGNOSTIC=1` is set in the environment.

There's currently no convenient macros for defining
types with the new flag, but you can do:

```c
_G_DEFINE_TYPE_EXTENDED_BEGIN (GtkAppChooserWidget,
                               gtk_app_chooser_widget,
                               GTK_TYPE_WIDGET,
                               G_TYPE_FLAG_DEPRECATED)
...
_G_DEFINE_TYPE_EXTENDED_END ()
```

Includes a unit test by Philip Withnall.
2022-11-09 12:07:31 +00:00
Philip Withnall
7b52ccbfc4 Revert "gio, glib: Use G_OS_DARWIN for code that is for such environments"
This reverts commit 476e33c3f3.

We’ve decided to remove `G_OS_DARWIN` in favour of recommending people
use `__APPLE__` instead. As per the discussion on #2802 and linked
issues,
 * Adding a new define shifts the complexity from “which of these
   platform-provided defines do I use” to “which platform-provided
   defines does G_OS_DARWIN use”
 * There should ideally be no cases where a user of GLib has to use
   their own platform-specific code, since GLib should be providing
   appropriate abstractions
 * Providing a single `G_OS_DARWIN` to cover all Apple products (macOS
   and iOS) hides the complexity of what the user is actually testing:
   are they testing for the Mach kernel, the Carbon and/or Cocoa user
   space toolkits, macOS vs iOS vs tvOS, etc

Helps: #2802
2022-11-07 11:30:32 +00:00
Marco Trevisan (Treviño)
476e33c3f3 gio, glib: Use G_OS_DARWIN for code that is for such environments
While we preserved the COCOA/CARBON cases when specific libraries are
needed.
2022-10-20 03:37:21 +02:00
Michael Catanzaro
8c54de8fa0 Fix build when G_DISABLE_CAST_CHECKS is defined to empty string
The usual use of G_DISABLE_CAST_CHECKS is to define it without giving it
a value. The value was never looked at until
f946e45a0c, where I decided it would be
cool to ignore it if defined to 0. But this broke the original usage, so
we need to revert that.

I thought it would be a good idea to look at the value in order to give
applications an off switch for the new behavior, so you could continue
to build optimized builds with cast checks enabled. We could still try
to find a way to do that in the future if desired, e.g. by introducing a
new G_ENABLE_CAST_CHECKS definition. But this doesn't seem especially
important. G_DISABLE_CAST_CHECKS is not documented anyway, so how we
handle cast checks is entirely up to GLib.
2022-10-18 13:58:14 +01:00
Philip Withnall
f946e45a0c Merge branch 'mcatanzaro/cast-checks' into 'main'
Automatically disable cast checks when building with optimization

See merge request GNOME/glib!2850
2022-10-14 15:26:35 +00:00
Xavier Claessens
e5565f6635 Rename all visibility macros 2022-10-13 20:53:56 -04:00
Xavier Claessens
dcfc9f689e Fix symbol visibility macros on Windows
There is currently no `dllimport` attribute on any of our function,
which prevents MSVC to optimize function calls.

To fix that issue, we need to redeclare all our visibility macros for
each of our libraries, because when compiling e.g. GIO code, we need
dllimport in GLIB headers and dllexport in GIO headers. That means they
cannot use the same GLIB_AVAILABLE_* macro.

Since that's a lot of boilerplate to copy/paste after each version bump,
this MR generate all those macros using a python script.

Also simplify the meson side by using `gnu_symbol_visibility : 'hidden'`
keyword argument instead of passing the cflag manually.

This leaves only API index to add manually into glib-docs.xml when
bumping GLib version. That file cannot be generated because Meson does
not allow passing a buit file to gnome.gtkdoc()'s main_xml kwarg
unfortunately.
2022-10-13 20:53:56 -04:00
Michael Catanzaro
b8e1ecdd6b Automatically disable cast checks when building with optimization
Cast checks are slow. We seem to have some rough consensus that they are
important for debug builds, but not for release builds. Problem is, very
few apps define G_DISABLE_CAST_CHECKS for release builds. Worse, it's
undocumented, so there's no way apps could even be expected to know
about it.

We can get the right default is almost all situations by making this
depend on the __OPTIMIZE__ preprocessor definition. This is a GCC-specific
thing, although Clang supports it too. If the compiler does not define
__OPTIMIZE__, then this commit does no harm: you can still use
G_DISABLE_CAST_CHECKS as before. When checking __OPTIMIZE__, we are
supposed to ensure our code has the same behavior as it would if we do
not, which will be true except in case the check fails (which is
programmer error).

Downside: this will not automatically do the right thing with -Og,
because __OPTIMIZE__ is always defined to 1. We don't want to disable
cast checks automatically if using -O0 or -Og. There's no way to
automatically fix this, but we can create an escape hatch by allowing
you to define G_DISABLE_CAST_CHECKS=0 to force-enable cast checks. In
practice, I don't think this matters much because -Og kinda failed:
GCC's man page says it should be a superior debugging experience to -O0,
but it optimizes variables away so it's definitely not.

Another downside: this is bad if you really *do* want cast checks in
release builds. The same solution applies: define
G_DISABLE_CAST_CHECKS=0 and you'll get your cast checks.
2022-08-03 16:18:17 -05:00
Philip Withnall
8385f52db7 Merge branch 'inline-macros' into 'main'
gmacros: Provide platform-independent G_ALWAYS_INLINE and G_NO_INLINE

See merge request GNOME/glib!2781
2022-07-06 13:40:10 +00:00
Marco Trevisan (Treviño)
a6f8fe071e cleanup: Replace G_GNUC_NO_INLINE with G_NO_INLINE
As per this we can also now mark G_GNUC_NO_INLINE as
GLIB_AVAILABLE_MACRO_IN_2_58, given that we don't have anymore headers
using it.
2022-07-06 14:57:06 +02:00
Philip Withnall
41691cc4c8 Merge branch 'more-spdx' into 'main'
Add more SPDX license headers

See merge request GNOME/glib!2706
2022-07-05 11:06:49 +00:00
Simon McVittie
5e164c6615 gtype: Add G_TYPE_FLAG_NONE
This makes code that sets no flags a bit more self-documenting:
using G_TYPE_FLAG_NONE makes it clearer that no special behaviour is
required than literal 0, and clearer that there is no weird casting
between types than (GTypeFlags) 0.

GTypeFlags and GTypeFundamentalFlags occupy the same namespace and the
same bitfield, so I intentionally haven't added
G_TYPE_FUNDAMENTAL_FLAGS_NONE.

Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-06-23 10:45:31 +01:00
Matthias Clasen
54c867a01e Revert "gtype: Speed up type checks for final types"
This reverts commit 0ddea2d8e2.

The commit was based on the misunderstanding that types
declared with G_DECLARE_FINAL_TYPE are actually non-derivable.
But that is only the case for types defined with
G_DEFINE_FINAL_TYPE.

Fixes: #2661
2022-06-06 16:39:41 -04:00
Philip Withnall
26409f19cd Add SPDX license headers for LGPL-2.1-or-later to various files
These have all been added manually, as I’ve finished all the files which
I can automatically detect.

All the license headers in this commit are for LGPL-2.1-or-later, and
all have been double-checked against the license paragraph in the file
header.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #1415
2022-06-01 12:44:23 +01:00
Matthias Clasen
0ddea2d8e2 gtype: Speed up type checks for final types
If a type is final, it is enough to compare the
instance type for equality, since it can't have
a derived type.
2022-05-30 00:10:32 -04:00
Matthias Clasen
22f51b87a2 gtype: Speed up g_type_is_a
As noticed by Christian Hergert: We can reduce
some overhead by checking for exact type
equality first. According to Christian, around
3% of g_type_is_a calls are exact equalities.
2022-05-20 09:08:09 -04:00
Logan Rathbone
3a4f0746f5 docs: Expand G_DEFINE_BOXED_TYPE docs with more detailed example 2022-04-25 10:39:27 +00:00
Gabor Karsay
7e64004db0 docs: mark macros, flags, enums with percent sign 2022-03-04 16:21:55 +00:00
Xavier Claessens
893ff61176 doc: Extend a bit G_DECLARE_* documentation example 2022-02-19 14:23:37 -05:00
Philip Withnall
7a8756d247 gobject: Add advice on larger alignment requirements for GObject members
We now guarantee that GObjects will always be allocated at least as
aligned as the basic types. If you want to put an element in your
GObject which has higher alignment requirements, we can’t guarantee it
will be aligned*. If you need it to be aligned, you’ll need to put it on
the heap (aligned appropriately), or add appropriate padding in your
GObject struct.

*Actually, GSlice will guarantee that the whole GObject is aligned to at
least the power of 2 greater than or equal to the size of the GObject,
which means any element in the GObject struct should always be
appropriate aligned if the compiler pads it appropriately. If malloc()
is used, however, it doesn’t make that guarantee, so we can’t make that
guarantee overall.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #1231
2021-11-17 11:56:20 +00:00
Philip Withnall
ed553e8e30 gtype: Eliminate -Wcast-align warnings with G_TYPE_CHECK_INSTANCE_CAST
Regardless of the actual alignment of the GTypeInstance in question,
these do a runtime check on the type, so if the type was originally
aligned correctly when allocated, it should be aligned correctly if the
type check succeeds. -Wcast-align is meant to warn about casts between
types, which this isn’t (if the check succeeds).

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #1231
2021-11-17 11:56:20 +00:00
Philip Withnall
0749643daa gobject: Assert that GObjects are at least as aligned as basic types
See the reasoning in the patch for why we believe GObjects *are*
(already) as aligned as the basic types.

We want to make this guarantee so that it’s guaranteed to be safe for
people to ignore -Wcast-align warnings for GObjects which contain basic
types. This typically happens with gdouble on 32-bit ARM platforms.

The checks are slightly complicated by the need to support GObjects with
custom constructors. We should expect that a custom construction
function will chain up to g_object_constructor (which calls
g_type_create_instance() as normal), but it’s possible that someone has
done something crazy and uses a custom allocator which doesn’t return
with the same alignment as GSlice. Hand them a warning in that case. If
that is true, the code which uses their custom-constructed GObject can
presumably already deal with the alignment it gets given.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #1231
2021-11-17 11:56:20 +00:00
Emmanuele Bassi
f62622fc7b docs: Start stanzas with a single paragraph
When rendering the contents of the GLib documentation stored inside the
introspection data, a common behaviour is to take the first paragraph as
a summary of the symbol being documented.

The documentation is assumed to be in Markdown format, which means:

 - paragraphs must be separated by newlines
 - lines that have an indentation of four or more spaces are considered
   code blocks
 - lines that start with a `#` are considered titles

This means we need to slightly tweak the documentation in our sources to
ensure that it can be rendered appropriately by tools that are not
gtk-doc.

See issue: #2365
2021-08-02 13:22:23 +01:00
Emmanuele Bassi
d1861c8fda Add G_DEFINE_* macros for final types
These should match the G_DECLARE_FINAL_* macros used in a header file.
2021-07-26 20:13:32 +01:00
Emmanuele Bassi
c07dd416cf gtype: Add a "final" flag
We want to have the ability to mark types that should not be derivable
even if they are in a deeply derivable type hierarchy; in other words,
leaf nodes in the types tree.
2021-07-26 20:13:32 +01:00
DarkTrick
ea365b7ea6 g_boxed_type_register_static: added reference to G_DEFINE_BOXED_TYPE 2021-07-22 12:16:41 +00:00
Nishal Kulkarni
98050b756b gtype: use G_GNUC_CHECK_VERSION
Replace `__GLIBC__` with `G_GNUC_CHECK_VERSION`
2021-04-29 17:40:14 +05:30
Philip Withnall
d4a875d8cd gtype: Improve formatting of GType documentation
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-01-20 15:42:55 +00:00
Philip Withnall
fab561f8d0 gobject: Drop use of volatile from get_type() macros
http://isvolatileusefulwiththreads.in/c/

It’s possible that the variables here are only marked as volatile
because they’re arguments to `g_once_*()`. Those arguments will be
modified in a subsequent commit.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #600
2020-11-20 14:40:19 +00:00
Sebastian Dröge
ddef9ba2f8 Merge branch 'instantiatable' into 'master'
gobject: Standardise on the term ‘instantiatable’

See merge request GNOME/glib!1735
2020-11-13 15:29:07 +00:00
Benjamin Otte
98f0a5a7da gtype: Add g_type_interface_instantiatable_prerequisite()
This function returns the most specific instantiatable type
that is a prerequisite for a given interface.

This type is necessary in particular when dealing with GValues
because a GValue contains an instance of a type.

This commit includes tests for the new API.
2020-11-02 17:36:18 +00:00
Philip Withnall
4f2b1e250d gobject: Standardise on the term ‘instantiatable’
Rather than using a mixture of ‘instantiable’ and ‘instantiatable’
everywhere, standardise on the term which is already in the public API.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2020-11-02 17:22:01 +00:00
Edward Hervey
898baa07b1 gobject: Handle runtime checks as such
The various `g_strdup_printf()` returns values in the implementations of GValue
lcopy_func are runtime checks which could be disabled if one wants and therefore
should be handled as such with g_return_val_if_fail()
2020-05-20 17:37:46 +02:00
Marco Trevisan (Treviño)
ab25fa42cc gtype: Define auto-cleanup functions for Module class
While we automatically define cleanup functions for the module, we don't
do it for the module class.

This will allow to manage the ownership of the class when reffing it
without having to cast it to GTypeClass.
2019-12-13 20:07:51 +01:00
Benjamin Otte
276e927fd4 Revert last 4 commits
This reverts commits:
  5899c61ed2
  e994d45352
  eb20dec144
  ebec0dd359
which wer accidentally pushed to master instead of a branch
2019-11-26 00:54:15 +01:00
Benjamin Otte
eb20dec144 gtype: Add g_type_interface_instantiable_prerequisite()
There is (at most) a single GType that is instantiable and a
prerequisite for an interface. This function returns that type.

This type is necessary in particular when dealing with GValues because a
GValue contains an instance of a type.
2019-11-25 20:06:39 +01:00
Matthew Waters
90f93a64f2 gtype: mark the inline functions in G_DECLARE_*_TYPE() as UNUSED
clang will warn about static inline functions where gcc will not.  Fixes
-Werror=unused-function with clang in dependant projects.
2019-08-28 18:08:29 +10:00
Emmanuele Bassi
4d73e1f014 Use GitLab to reserve a new fundamental type slot
Even though you *really* shouldn't do that at all.
2019-07-23 11:27:30 +01:00
Emmanuel Fleury
79da3551e3 Fix typo in G_DECLARE_DERIVABLE_TYPE documentation
Closes issue #1838
2019-07-20 16:05:12 +02:00
Emmanuele Bassi
87016536a6 Improve the documentation for G_DEFINE_TYPE_WITH_PRIVATE
Connect the dots between G_ADD_PRIVATE and the various G_DEFINE_* macros
that use it, as well as expanding the code example for
G_DEFINE_TYPE_EXTENDED with a private instance data declaration.

Closes: #943
2019-07-14 17:50:35 +01:00
Philip Withnall
40ff475977 Annotate various types and macros as deprecated
These have all been documented as deprecated for a long time, but we’ve
never had a way to programmatically mark them as deprecated. Do that
now.

This is based on the list of deprecations from the reverted commit
80fcb1bc2.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #638
2019-05-30 10:39:11 +01:00
Emmanuele Bassi
e5ba5845a1 Revert "headers: Add various missing G_DISABLE_DEPRECATED guards"
This reverts commit 80fcb1bc26.

G_DISABLE_DEPRECATED should never be used by anybody, least of all by
GLib. We have deprecation annotations for the compiler, these days, and
they are much better suited than a macro that makes symbols appear and
disappear. The fact that gtk-doc doesn't understand the deprecation
annotations is a limitation of gtk-doc, and it's gtk-doc that ought to be
fixed.

Commit 80fcb1bc broke GStreamer, which disables old API that was
deprecated before the introduction of the deprecation annotations, but
still uses newly deprecated one, and relies on the deprecation
annotations to do their thing. It also broke libsoup, as it uses
GValueArray in its own API.
2019-03-16 11:30:13 +00:00
Philip Withnall
80fcb1bc26 headers: Add various missing G_DISABLE_DEPRECATED guards
As pointed out by gtk-doc, these are all symbols which have been marked
as deprecated, but which aren’t protected by a deprecation guard. We
can’t use G_DEPRECATED_IN_* for them, as they are all non-function
symbols. Instead, wrap them in #ifndef G_DISABLE_DEPRECATED.

In some cases, we also need to wrap one or two functions which use the
deprecated types in G_DISABLE_DEPRECATED too.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-15 11:09:32 +00:00
Emmanuele Bassi
4f5f34689f Merge branch 'interface-docs' into 'master'
gtype: Clarify type of GInterfaceInitFunc

See merge request GNOME/glib!512
2019-01-07 14:40:44 +00:00
Philip Withnall
154b24c055 gtype: Document type for iface_default_init() function
And mention why it’s not a GInterfaceInitFunc as people who have read
the GObject docs cover-to-cover might expect.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-12-27 23:46:42 +00:00
Kouhei Sutou
b8ac6e146a Suppress -Wint-in-bool-context warning with G_DEFINE_INTERFACE and g++
Note that it's not reported with gcc. It's only reported with g++.

C++ code to reproduce this warning:

    #include <glib-object.h>

    G_BEGIN_DECLS

    #define GARROW_TYPE_FILE (garrow_file_get_type())
    G_DECLARE_INTERFACE(GArrowFile,
                        garrow_file,
                        GARROW,
                        FILE,
                        GObject)

    struct _GArrowFileInterface {
      GTypeInterface g_iface;
    };

    G_DEFINE_INTERFACE(GArrowFile,
                       garrow_file,
                       G_TYPE_OBJECT)

    static void
    garrow_file_default_init(GArrowFileInterface *iface)
    {
    }

    G_END_DECLS

Build command line:

    % g++ -Wall -shared -o liba.so a.cpp $(pkg-config --cflags --libs gobject-2.0)

Message:

    In file included from /tmp/local.glib/include/glib-2.0/gobject/gobject.h:24,
                     from /tmp/local.glib/include/glib-2.0/gobject/gbinding.h:29,
                     from /tmp/local.glib/include/glib-2.0/glib-object.h:23,
                     from a.cpp:1:
    a.cpp: In function 'GType garrow_file_get_type()':
    /tmp/local.glib/include/glib-2.0/gobject/gtype.h:219:50: warning: '<<' in boolean context, did you mean '<' ? [-Wint-in-bool-context]
     #define G_TYPE_MAKE_FUNDAMENTAL(x) ((GType) ((x) << G_TYPE_FUNDAMENTAL_SHIFT))
                                                 ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /tmp/local.glib/include/glib-2.0/gobject/gtype.h:2026:11: note: in definition of macro '_G_DEFINE_INTERFACE_EXTENDED_BEGIN'
           if (TYPE_PREREQ) \
               ^~~~~~~~~~~
    /tmp/local.glib/include/glib-2.0/gobject/gtype.h:1758:47: note: in expansion of macro 'G_DEFINE_INTERFACE_WITH_CODE'
     #define G_DEFINE_INTERFACE(TN, t_n, T_P)      G_DEFINE_INTERFACE_WITH_CODE(TN, t_n, T_P, ;)
                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
    a.cpp:16:1: note: in expansion of macro 'G_DEFINE_INTERFACE'
     G_DEFINE_INTERFACE(GArrowFile,
     ^~~~~~~~~~~~~~~~~~
    /tmp/local.glib/include/glib-2.0/gobject/gtype.h:178:25: note: in expansion of macro 'G_TYPE_MAKE_FUNDAMENTAL'
     #define G_TYPE_OBJECT   G_TYPE_MAKE_FUNDAMENTAL (20)
                             ^~~~~~~~~~~~~~~~~~~~~~~
    a.cpp:18:20: note: in expansion of macro 'G_TYPE_OBJECT'
                        G_TYPE_OBJECT)
                        ^~~~~~~~~~~~~
2018-12-20 11:24:53 +09:00
Philip Withnall
21adb30a83 gtype: Clarify type of GInterfaceInitFunc
When passing a function to G_IMPLEMENT_INTERFACE, it actually has to
take two arguments. Who knew?

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-12-05 14:09:35 +00:00
Emmanuele Bassi
7e5db31d36 Deprecate g_type_class_add_private()
It's been 4 years and 8 development cycles since we introduced
G_ADD_PRIVATE and offset-based private data access. It is now
time to finally deprecate the old mechanism.

Closes: #699
2018-06-14 11:33:53 +01:00