Commit Graph

27884 Commits

Author SHA1 Message Date
Matthias Clasen
682e9c9f56 docs: Move migrating-gdbus.xml to Markdown
This copies the test code inline into the Markdown, which means it could
diverge from the test code which is compiled and run as part of the
tests. That needs improving, but that can happen in a subsequent commit.

Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
e1d6168e5b docs: Move the auto-cleanup documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
c2798e6c2a docs: Move building documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
abf99f533f docs: Move compiling documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
4784bb10b1 docs: Move the cross-compilation documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
057f4fa2a5 docs: Move GVariant Format Strings documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
5d80471d4b docs: Move the GVariant Text Format documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
758c5de24e docs: Move the ‘running GLib’ documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
7c5fc4eb26 docs: Move the GSlice documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
0d05b87b9f docs: Move GObject concepts/intro to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
390d9a446d docs: Move GModule documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
fc29022f0b docs: Move GIO overview to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
c09f48bb28 docs: Move migrating-gnome-vfs.xml to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
221ba4e211 docs: Move migrating-gconf.xml to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
4411023462 docs: Move GValue documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
e298f1a078 docs: Move floating refs documentation to Markdown
And add some new sections on strategies for avoiding designing APIs
around floating refs.

Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
58019515d6 docs: Move enum type documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
24e93078d3 docs: Move boxed type documentation to Markdown
And add some additional new content and examples.

Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
1a090564d2 docs: Move GTest/test framework documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
d8b25ecda3 docs: Move GMainLoop documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
6c6337aa27 docs: Move macros documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
48c70b557e docs: Move logging documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
7b954a8d15 docs: Move i18n documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
46eed6009b docs: Move GError documentation to Markdown
Helps: #3037
2023-10-11 14:01:29 +01:00
Matthias Clasen
a73d3d7b8f docs: Move byte conversion macro documentation to Markdown
Helps: #3037
2023-10-11 14:01:28 +01:00
Matthias Clasen
9725c012b1 docs: Move character set conversion docs to Markdown
Helps: #3037
2023-10-11 14:01:28 +01:00
Matthias Clasen
0b56387ad5 docs: Move GThread documentation to Markdown
Helps: #3037
2023-10-11 14:01:28 +01:00
Matthias Clasen
c3713e1b67 docs: Move GRcBox/GArcBox and refcounting docs to Markdown
Helps: #3037
2023-10-11 14:01:28 +01:00
Philip Withnall
6107f50cc7 build: Disable gtk-doc unit tests
As we start moving documentation over from gtk-doc to gi-docgen, the
gtk-doc coverage is going to go down and things are going to start
breaking. That’s OK; we don’t need to test it any more.

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

Helps: #3037
2023-10-11 14:01:28 +01:00
Matthias Clasen
39e9ef54be docs: Add initial support for using gi-docgen for docs
The files here are copied from the docs-gtk-org
branch of gtk.

This adds gi-docgen to the CI Dockerfiles and ensures the new versions
(including the OS upgrades from the previous commit) are used during CI.

Helps: #3037
2023-10-11 14:01:28 +01:00
Philip Withnall
9dd59ba8ad ci: Ignore a ‘dubious ownership’ warning when updating submodules
It’s irrelavent.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2023-10-11 14:01:28 +01:00
Philip Withnall
13c3595363 ci: Upgrade CI images to the new oldest-supported OS versions
That means Debian Bookworm and Fedora 37.

Also rework the mingw Dockerfile to be based on the Fedora one, so that
the underlying layers can be shared. This should reduce the disk
consumption of the registry a little.

`.gitlab-ci.yml` has not been updated to use the new images in this
commit, as the images will be modified further in the following commit.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2023-10-11 13:54:13 +01:00
Sergey Bugaev
2ec660b2ea Stop using enums in bitfields
The C standard does not specify whether the underlying type of an enum
is signed or unsigned, and until C23 there was no way to control this
explicitly. GCC appears to make enums unsigned unless there is a
negative value among cases of the enum, in which case it becomes signed.
MSCV appears to make enums signed by default.

A bitfield of an enum type (which is not specificied in the C standard
either) behaves as if it was an instance of a numeric type with a
reduced value range. Specifically, a 'signed int val : 2;' bitfield will
have the possible values of -2, -1, 0, and 1, with the usual wraparound
behavior for the values that don't fit (although this too is
implementation-defined).

This causes the following issue, if we have:

typedef enum
{
  G_ZERO,
  G_ONE,
  G_TWO
} GFoo;

struct _GBar
{
  GFoo foo : 2;
};

and then assign bar.foo = G_TWO and read it back, it will have the
expected value of 2 (aka G_TWO) on GCC, but a value of -2 (not matching
any of the enum variants) on MSVC.

There does not seem to be any way to influence signedness of an enum
prior to C23, nor is there a 'unsigned GFoo foo : 2;' syntax. The only
remaining options seems to be never using enums in bitfields, which is
what this change implements.

This corresponds to https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6467
in GTK.

Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
2023-10-11 15:05:57 +03:00
Philip Withnall
2f5088b7b6 Merge branch 'resources-alignment' into 'main'
glib-compile-resources: ensure alignment is at least sizeof(void *)

See merge request GNOME/glib!3630
2023-10-10 21:23:46 +00:00
Alex Richardson
9abbf2eec2 glib-compile-resources: ensure alignment is at least sizeof(void *)
This triggered a warning from the CHERI compiler since the struct contains
a `void *` but `__attribute__((aligned(8))` reduced alignment to less than
the `void *` alignment (which is 16 for Arm Morello).

Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
2023-10-10 08:44:58 -07:00
Philip Withnall
f7d2a58be6 Merge branch 'tests_meson_targets' into 'main'
glib/tests/meson.build: remove identical build targets

See merge request GNOME/glib!3629
2023-10-10 09:51:36 +00:00
Hannes Müller
5a1300db0a glib/tests/meson.build: remove identical build targets
If no error with -Werror=sign-conversion, the resulting object file
does not differ from compilation without -Werror=sign-conversion.
So the -Werror argument is now applied directly to string.c and testing.c.
Finally, the currently specific -Werror targets string-macro and
testing-macro are removed.
2023-10-10 11:16:25 +02:00
Philip Withnall
7e8fb7ba24 Merge branch 'hurd-codeowners' into 'main'
Add Hurd code owners

See merge request GNOME/glib!3627
2023-10-09 23:01:06 +00:00
Philip Withnall
8da3a5bb3e Merge branch 'stdio-include' into 'main'
glib-unix: Use full path to gstdio.h include

See merge request GNOME/glib!3628
2023-10-09 22:34:57 +00:00
Philip Withnall
2191b5aa05 glib-unix: Use full path to gstdio.h include
This fixes use of `glib-unix.h` from outside the GLib build path.

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

See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3457#note_1864368
2023-10-09 22:18:18 +01:00
Philip Withnall
9b51346237 Merge branch 'wip/smcv/auto-unix-pipe' into 'main'
glib-unix: Add convenience API for pipes

See merge request GNOME/glib!3457
2023-10-09 18:00:36 +00:00
Simon McVittie
e80b0c4e4b gspawn: Use GUnixPipe on Unix
Signed-off-by: Simon McVittie <smcv@collabora.com>
2023-10-09 18:44:38 +01:00
Simon McVittie
9e20a7d0e7 tests: Exercise GUnixPipe
Signed-off-by: Simon McVittie <smcv@collabora.com>
2023-10-09 18:44:38 +01:00
Simon McVittie
26c7b308ba tests: Break out assert_fd_was_closed() into a header
Signed-off-by: Simon McVittie <smcv@collabora.com>
2023-10-09 18:44:38 +01:00
Simon McVittie
f31db7d370 glib-unix: Add convenience API for pipes
We can't easily use g_autofd with g_unix_open_pipe, because its
parameter is an array of two fds that both need closing. Add an inline
convenience wrapper providing the obvious semantics.

Signed-off-by: Simon McVittie <smcv@collabora.com>
2023-10-09 18:44:38 +01:00
Philip Withnall
240156d174 Merge branch '3098-keyfile-escaping' into 'main'
Revert "gkeyfile: Temporarily re-allow invalid escapes when parsing strings"

Closes #3098

See merge request GNOME/glib!3618
2023-10-09 16:50:56 +00:00
Simon McVittie
6fd1037361 gspawn: Use g_clear_fd() instead of reinventing it
g_clear_fd() is documented to be async-signal safe whenever the
fd is either negative or valid (which it should be here) and the error
is NULL (which it always is here).

Signed-off-by: Simon McVittie <smcv@collabora.com>
2023-10-09 17:42:04 +01:00
Sergey Bugaev
e50cba31f6 docs: Add bugaevc and sthibaul as Hurd code owners
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
2023-10-09 15:08:38 +03:00
Philip Withnall
e93e1cb547 Merge branch 'g-wakeup-eintr-check' into 'main'
wakeup: Fix g_wakeup_acknowledge if signal comes in

See merge request GNOME/glib!3624
2023-10-05 16:53:54 +00:00
Ray Strode
7bbd4328f6 wakeup: Fix g_wakeup_acknowledge if signal comes in
It's not very likely, but there is a small chance that an
incoming signal could disturb the non-blocking read calls in
g_wakeup_acknowledge, leading to a subsequent spurious wake up.

This commit addresses the problem by doing the usual EINTR
loop (which is already present on the write side incidentally)
2023-10-05 09:55:49 -04:00