Use correct trigraphs to skip enum members.

[mwleeds]

Avoid warnings like these:
[14/448] Generating as-enum-types.h with a meson_exe.py custom command.
WARNING: Failed to parse "/< private >/" in
/home/mwleeds/git/gnome-software/build/../subprojects/appstream/src/as-agreement.h

Based on this commit
https://gitlab.gnome.org/GNOME/gnome-software/-/commit/512e606085c7e325ce6e4658346da2f3c5f2cdfc

[ximion]

This will break API documentation if merged, and the issue has actually already been fixed (again) in GLib after the original fix went missing by accident: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1870
So I'd actually rather just wait for the fixed GLib version to show up everywhere.

[ximion]

Hmm, upon reading the gnome-software commit message, it's actually debatable whether the *_LAST enums actually should be visible in the documentation, as opposed to being private. I am kind of leaning towards not exposing them in the documentation though (I would also be trading a mkenums warning for a gtk-doc warning as none of the _LAST enums are properly documented).

What do you think? Recent GLib versions definitely remove the noise when building AppStream and other libraries using the private annotation, so that is a temporary annoyance - as for the "should documentation include it?" I am not so sure though. A quick look at other docs seems to indicate that this is often omitted though (but also surprisingly few projects seem to use this paradigm).

[mwleeds]

This will break API documentation if merged, and the issue has actually already been fixed (again) in GLib after the original fix went missing by accident: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1870
So I'd actually rather just wait for the fixed GLib version to show up everywhere.

Okay, wasn't aware of that MR

[mwleeds]

Hmm, upon reading the gnome-software commit message, it's actually debatable whether the *_LAST enums actually should be visible in the documentation, as opposed to being private. I am kind of leaning towards not exposing them in the documentation though (I would also be trading a mkenums warning for a gtk-doc warning as none of the _LAST enums are properly documented).

What do you think? Recent GLib versions definitely remove the noise when building AppStream and other libraries using the private annotation, so that is a temporary annoyance - as for the "should documentation include it?" I am not so sure though. A quick look at other docs seems to indicate that this is often omitted though (but also surprisingly few projects seem to use this paradigm).

Are there any use cases for these enums that are external to the library? For that matter what are the use cases within libraries?

[ximion]

Are there any use cases for these enums that are external to the library? For that matter what are the use cases within libraries?

Mostly for iterating through all the values of an enum.
For example, you could do this:

for (guint i = 0; i < AS_COMPONENT_KIND_LAST; i++)
    g_print ("%s\n", as_component_kind_to_string ((AsComponentKind) i));

It is also very useful for sanity checks:

guint value = 42;
g_assert (value >= 0 && value < AS_COMPONENT_KIND_LAST);

With having the _LAST entry always last, this code is always up to date whenever a new enum value was added (external apps need to be recompiled to take advantage of the new enum of course).
So yeah, there are usecases within the library and external tools, but the _LAST enum isn't actually any useful value for the enum per-se. It's more part of the general API for every enum type (many non-C languages have some kind of enum iteration built-in, in C we fake it with this).

By the way, in order to get rid of the warnings, GLib >= 2.67.3 is required, which admittedly is currently a very high requirement. Ironically some older versions will not show these warning too, as the warnings are actually a recent regression.