The `type` field will eventually disappear, so use an accessor method to
get it.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
These aren’t needed at the moment, since all the `TypeInfo` structs in
libgirepository are all aliases for each other.
An upcoming commit will change that, however, so we need to be a little
bit stricter about type safety in advance.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
These methods don’t return a `GType`, so when the code gets ported to
`GTypeInstance` in an upcoming commit, that will become quite confusing.
Rename them all to `get_type_info()` instead.
This introduces no functional changes, but it is an API break.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Move the SECTION into the struct docs, update the documentation comment
syntax, and add `Since: 2.80` everywhere.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Move the SECTION into the struct docs, update the documentation comment
syntax, and add `Since: 2.80` everywhere.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Move the SECTION into the struct docs, update the documentation comment
syntax, and add `Since: 2.80` everywhere.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Otherwise the GIR generation for libgirepository doesn’t work, as GLib
doesn’t get pulled in to provide basic types.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Alpine 3.19 ships with Meson 1.3.0, which has broken handling of File
objects and their paths. This causes (as far as I can tell)
un-work-around-able breakage of GLib’s build.
See https://github.com/mesonbuild/meson/issues/5273#issuecomment-1851811417
That should be fixed in Meson 1.4.0, but that might not be released for
a while. Because we’re here to test GLib, not Meson, let’s pin the Meson
version in the Alpine CI image to 1.2.3, which we know works and is
reasonably up to date (and is what the other CI images use).
Fixes this CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/3361388
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This is just the result of running `black $(git ls-files '*.py')`.
For some reason, the `sh-and-py-check` CI job didn’t run on merge
request !3751, so this non-standard formatting slipped through onto
`main`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3754#note_1939914
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It can cause failures for shared connection objects.
What can currently happen is this:
1. A user starts to asynchronously create a proxy object
2. A user starts to asynchronously create another proxy object
At this point, the asynchronous initialization for the two proxy objects
share the not yet initialized connection object.
3. While the shared connection objected is created, the user cancels the
creation with the supplied cancellable from the fist proxy object.
4. initable_init caches the canceled error and marks the connection as
initialized.
5. The initialization of the second proxy object fails with the same
canceled error.
To avoid this, clear the error in this case and destroy any member
variables that may have been created before the creation was canceled.
This way, the initialization of the second proxy object will restart the
connection initialization and with probably succeed.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Before checking the properties of `*_proxy`, assert that there were no
errors in constructing the proxy first. Otherwise the property checks
will crash on `NULL` pointer dereferences.
The test is still intermittently buggy somewhere, but at least this
commit will cause a relevant error message to be printed on failure.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
There is no reason for key and value to have different annotations.
Both may return NULL as a valid value.
gpointer typed parameters are nullable by convention, so there is
no change here. The (nullable) annotation is just for humans really.
Just for debugging purposes, track whether the Connection Attempt Delay
(https://datatracker.ietf.org/doc/html/rfc8305#section-8) has been
reached for each attempt.
This makes it a bit easier to diagnose `GSocketClient` problems in a
debugger.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
