After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 615923 - g-i failed to parse enum
g-i failed to parse enum
Status: RESOLVED NOTABUG
Product: gobject-introspection
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2010-04-16 05:17 UTC by Danielle Madeley
Modified: 2018-01-24 17:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Danielle Madeley 2010-04-16 05:17:48 UTC 
<enumeration name="ContactFeature"
                 doc=".... cut ...."
                 version="0.7.18"
                 c:type="TpContactFeature">
      <member name="p_contact_feature_alias"
              value="0"
              c:identifier="TP_CONTACT_FEATURE_ALIAS"/>
      <member name="p_contact_feature_avatar_token"
              value="1"
              c:identifier="TP_CONTACT_FEATURE_AVATAR_TOKEN"/>
      <member name="p_contact_feature_presence"
              value="2"
              c:identifier="TP_CONTACT_FEATURE_PRESENCE"/>
      <member name="p_contact_feature_location"
              value="3"
              c:identifier="TP_CONTACT_FEATURE_LOCATION"/>
      <member name="um_tp_contact_features"
              value="4"
              c:identifier="NUM_TP_CONTACT_FEATURES"/>
    </enumeration>

typedef enum {
    TP_CONTACT_FEATURE_ALIAS,
    TP_CONTACT_FEATURE_AVATAR_TOKEN,
    TP_CONTACT_FEATURE_PRESENCE,
    TP_CONTACT_FEATURE_LOCATION,
    NUM_TP_CONTACT_FEATURES
} TpContactFeature;

Guessing that NUM_TP_CONTACT_FEATURES breaks it. Is there a way to skip this value from the introspected output?
Comment 1 Simon McVittie 2010-04-16 12:11:44 UTC 
We could work around this by turning NUM_TP_CONTACT_FEATURES into a #define like we do in telepathy-glib's generated code, as it's (strictly speaking) not really part of the enum.
Comment 2 Johan (not receiving bugmail) Dahlin 2010-09-06 16:33:53 UTC 
Can you retry this on trunk, the recent scanner rewrite might have fixed this.
Comment 3 Danielle Madeley 2010-09-10 02:46:17 UTC 
Still an issue.
Comment 4 Emmanuele Bassi (:ebassi) 2013-08-26 11:27:58 UTC 
three years passed: is this still a problem in Telepathy?

to be fair, the last enumeration value is pretty much against all best practises for enumeration values in GObject; I'm actually surprised it does not break glib-mkenums as well.
Comment 5 Simon McVittie 2013-08-27 10:25:30 UTC 
(In reply to comment #4)
> three years passed: is this still a problem in Telepathy?

We avoided it, initially by turning it into a #define, then later by renaming it to TP_NUM_THINGS.

I think it makes more sense for it to be a #define anyway, tbh - it isn't a valid value of TpContactFeature (and when we add more features, its value will increase so it *still* isn't a valid value), so it should be outside the enum.

> to be fair, the last enumeration value is pretty much against all best
> practises for enumeration values in GObject

Yeah, I'd be OK with calling this INVALID or something.
Comment 6 André Klapper 2015-02-07 17:16:54 UTC 
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
Comment 7 Emmanuele Bassi (:ebassi) 2018-01-24 17:01:47 UTC 
Closing as NOTABUG, as per comment 5