GNOME Bugzilla – Bug 690850
g-ir-scanner should print the filename/line if it crashes when parsing gtk-doc annotations
Last modified: 2015-02-07 17:01:31 UTC
(As suggested by Suloev Dmitry in https://bugs.gentoo.org/show_bug.cgi?id=448992) Currently, when g-ir-scanner gets an exception when parsing a gtk-doc annotation via _parse_comment_block(), it simply bails out with a backtrace, for example: Traceback (most recent call last):
+ Trace 231324
comment_block = self.parse_comment_block(comment)
return self._parse_comment_block(comment_lines, filename, lineno)
if comment_block.comment:
Crashing when encountering an exception in _parse_comment_block() may be reasonable, but the stack trace message being printed is by itself unhelpful. In most cases, exceptions in _parse_comment_block() are caused by annotation syntax errors in the C file being parsed, so the developer would want to know which file and which line in the C file may have been responsible for the problem.
Created attachment 232365 [details] [review] proposed patch This patch adds information about the C filename and line to the backtrace when crashing due to an exception from parse_comment_block()
Review of attachment 232365 [details] [review]: Besides my remark on the usage of message.fatal() this looks OK, although I'm not sure we really want to mask all errors like this instead of hardening the GTK-Doc parser when a bug is encountered at this point in time... ::: giscanner/annotationparser.py @@ +772,3 @@ + except: + message.fatal("error when parsing comment block\n%s" % traceback.format_exc(), + message.Position(comment[1], comment[2])) It has been agreed before that "syntax errors" while parsing GTK-Doc comment blocks (or comment blocks pretending to be GTK-Doc) should never result in g-ir-scanner giving up but message.fatal() calls SystemExit(). Ignoring a comment block that results in a "syntax error" and optionally emitting a warning is OK.
Created attachment 232615 [details] [review] giscanner: Don't fail on empty GTK-Doc comment blocks giscanner: Don't fail on empty GTK-Doc comment blocks A completely empty GTK-Doc comment block (/**\n*/) resulted in an unfriendly backtrace, complaining about an "AttributeError: 'NoneType' object has no attribute 'comment'" This fixes the issue and adds a test case.
Created attachment 232616 [details] [review] tests: add invalid identifier test case tests: add invalid identifier test case This comment block, as found in the wild via https://bugzilla.gnome.org/show_bug.cgi?id=690850 has a couple of elements to make it an interesting test case: - a colon on the first line - stuff between parens on the first line but it still isn't a valid identifier. Add it here anyway to make sure we don't regress.
Both attachment #232615 [details] and attachment #232615 [details] are meant for master. I don't know if there are plans for a 1.34.1 maintenance release but if there are, I'll happily backport these patches.
Review of attachment 232615 [details] [review]: Looks good.
Review of attachment 232616 [details] [review]: Hm, and the previous patch fixes this? Looks good in that case.
Created attachment 233103 [details] [review] giscanner: emit a warning when we fail to parse a GTK-Doc comment block Same thing as in comment #1 but taking into account the remarks from comment #2
Review of attachment 233103 [details] [review]: One comment. ::: giscanner/annotationparser.py @@ +769,3 @@ + try: + comment_block = self.parse_comment_block(comment) + except: catch-all except clauses are not a great idea (e.g. they also catch KeyboardInterrupt): http://stackoverflow.com/questions/4990718/python-about-catching-any-exception Can we just handle a specific set of exceptions?
Created attachment 233114 [details] [review] giscanner: emit a warning when we fail to parse a GTK-Doc comment block Patch taking into account comment #9
Created attachment 233115 [details] [review] giscanner: emit a warning when we fail to parse a GTK-Doc comment block Now without the unrelated whitespace change that got in there :/
Review of attachment 233115 [details] [review]: Looks good!
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]