GNOME Bugzilla – Bug 552066
Need to handle deprecated code inside #ifndef GTK_DISABLE_DEPRECATED
Last modified: 2018-02-08 11:44:22 UTC
Please describe the problem: GtkArg for example carries no indication of its deprecated status. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Created attachment 118713 [details] [review] parse gtk-doc Deprecated
There are multiple parts to support here - GtkArg is actually somewhat tricky because it's a pure structure definition in the .h file, under #ifndef GTK_DISABLE_DEPRECATED. For functions and the like, the way this is specified is in the gtk-doc with a Deprecated: tag. The above patch parses that, but does not attempt to handle the header.
(In reply to comment #1) > Created an attachment (id=118713) [edit] > parse gtk-doc Deprecated > Looks pretty good I wouldn't mind having this committed as is, however: - Does it make sense to include the version it was deprecated in? - Separating annotation parsing from normal parsing would be useful, so it can be enabled/disabled by a command line parameter in the future - Moving more of the gtk-doc parsing to python would make sense here.
Created attachment 118744 [details] [review] include full deprecation information This patch includes both the version and the comment (see the diff to annotation-expected.gir).
(In reply to comment #3) > - Separating annotation parsing from normal parsing would be useful, > so it can be enabled/disabled by a command line parameter in the future > - Moving more of the gtk-doc parsing to python would make sense here. All for that, but I am not very familiar with the code and unsure how to do so.
(In reply to comment #4) > Created an attachment (id=118744) [edit] > include full deprecation information > > This patch includes both the version and the comment (see the diff to > annotation-expected.gir). I'd prefer separate tags, so users of the gir doesn't have to do any extra string parsing to get that information. Better to do a bit of more work in the scanner to make the life easier for gir users. (In reply to comment #5) > (In reply to comment #3) > > > - Separating annotation parsing from normal parsing would be useful, > > so it can be enabled/disabled by a command line parameter in the future > > - Moving more of the gtk-doc parsing to python would make sense here. > > All for that, but I am not very familiar with the code and unsure how to do so. Neither am I, I guess this can wait. I just know that the C parsing code is fragile and that I personally would much rather use Python to do that.
Created attachment 118758 [details] [review] split out version
Comment on attachment 118758 [details] [review] split out version >diff --git a/giscanner/ast.py b/giscanner/ast.py > def __init__(self, name=None): > self.name = name >+ self.deprecated = None It would make more sense to add deprecated_version here (or perhaps deprecated_since)... >diff --git a/giscanner/girwriter.py b/giscanner/girwriter.py >+ def _append_deprecated(self, node, attrs): >+ if node.deprecated: >+ (deprecated_version, deprecated_str) = node.deprecated ... then you would avoid this. >+ attrs.append(('deprecated', deprecated_str.strip())) >+ if deprecated_version: >+ attrs.append(('deprecated-version', >+ deprecated_version.strip())) strip():ing should be done in the parsing, not in the wriring. >diff --git a/giscanner/transformer.py b/giscanner/transformer.py >+ try: >+ # Split out gtk-doc version >+ func.deprecated = deprecated[0].split(':', 1) >+ except ValueError, e: >+ # No version, just include str >+ func.deprecated = (None, deprecated[0]) I usually prefer to do a if ':' in deprecated, but it's not a big deal, do as you like. >+ <function name="object_do_not_use" >+ c:identifier="annotation_object_do_not_use" >+ deprecated="Use annotation_object_create_object() instead." >+ deprecated-version="0.12"> Looks good! You can commit this if you address the comments above.
Reopening this bug until we also correctly handle #ifndef GTK_DISABLE_DEPRECATED.
It would be nice to have deprecated classes marked as deprecated too, not only functions.
Created attachment 200949 [details] [review] Parse deprecated/deprecated_for macros
I have a patch at my laptop at home which adds the following on top of attachment 200949 [details] [review] deprecated -> c:deprecated-for deprecated-version -> c:deprecated-version new attribute: c:deprecated, 0 is default, 1 means the functions is deprecated, similar to what we have in the tgir No girepository/typelib changes will be necessary.
Created attachment 201032 [details] [review] Parse deprecated/deprecated_for macros
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/1.