summaryrefslogtreecommitdiff
path: root/giscanner/annotationparser.py
Commit message (Collapse)AuthorAgeFilesLines
* giscanner: emit a warning when we fail to parse a GTK-Doc comment blockDieter Verfaillie2013-01-091-1/+7
| | | | | | | | | | | Instead of going down with a for the user inexplicable backtrace, emit a warning asking said user to file a bug including the comment block in question. Thanks to Alexandre Rostovtsev <tetromino@gentoo.org> for proposing something similar in bug #690850 https://bugzilla.gnome.org/show_bug.cgi?id=690850
* giscanner: Don't fail on empty GTK-Doc comment blocksDieter Verfaillie2013-01-091-11/+14
| | | | | | | | | | 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. https://bugzilla.gnome.org/show_bug.cgi?id=690850
* scanner: Parse comments with */ not on a new line, but emit a warningDieter Verfaillie2012-12-021-4/+21
| | | | | | We don't know how many apps do this, but at least ibus had one. https://bugzilla.gnome.org/show_bug.cgi?id=689354
* giscanner: don't continue parsing after multiline descriptionsDieter Verfaillie2012-11-281-2/+2
| | | | | | | | | | This doesn't change anything, really, except that you don't have to read a whole page of code just to realize that nothing else happens with that line and we go on processing the next. Putting the continue statements there makes it a bit more readable. https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner: fix DocBlock().commentDieter Verfaillie2012-11-281-5/+4
| | | | | | | | | If there is no comment block description, DocBlock().comment should be None. This results in the removal of unneeded blank lines in the output of DocBlock().to_gtk_doc and hence the .c files generated by misc/update-glib-annotations.py https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner: update annotationparser to most recent gtkdoc-mkdb bug fixes.Dieter Verfaillie2012-11-281-3/+29
| | | | | | | This patch adds a test for and implements a more generic solution to GTK-Doc commit 47abcd53b8489ebceec9e394676512a181c1f1f6 https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner: remove re.MULTILINE usage from annotationparserDieter Verfaillie2012-11-281-12/+11
| | | | | | | These are remnants from the original prototype and are no longer used. https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner: Correctly detect invalid GTK-Doc comment block end markersDieter Verfaillie2012-11-281-0/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner: treat the GTK-Doc Description: tag like any other tagDieter Verfaillie2012-11-281-14/+19
| | | | | | and add paragraph break tests. https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner: construct list of possible tag names for TAG_RE from _ALL_TAGS...Dieter Verfaillie2012-11-281-5/+219
| | | | | | | | ... instead of having a secondary hard-coded list. This results in the removal of giscanner/annotationpatterns.py to prevent a circular import. https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner: use re.match() instead of re.search()Dieter Verfaillie2012-11-281-10/+10
| | | | | | | | | | | | | | | From Python's documentation: Python offers two different primitive operations based on regular expressions: match checks for a match only at the beginning of the string, while search checks for a match anywhere in the string (this is what Perl does by default). The different behavior between match() and search() doesn't matter in our case and conceptually we are checking if a piece of text matches a certain pattern, so match() is a better fit. https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner: drop dead codeDieter Verfaillie2012-11-281-10/+2
| | | | | | | | DocOptions already has a position attribute, no need to overwrite it when the position of DocBlock or DocTag is set, hence the set_position methods are no longer needed. https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner: make it clear DocOptions() also has a position attributeDieter Verfaillie2012-11-281-0/+1
| | | | | | | Lost a couple of hours hunting down a failed test case (from the annotationparser work about to land) due to this not being clear... https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner: implement DocOption() in terms of odict instead of dictDieter Verfaillie2012-11-281-1/+1
| | | | | | | | | The order of the "options" key/value pairs returned by DocOption().all() should be identical to the order in which they where stored. Hence replace the dict usage with odict. https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner: remove unused variablesDieter Verfaillie2012-11-281-13/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner: use dict.values() in favor of dict.itervalues()Dieter Verfaillie2012-11-281-2/+2
| | | | | | | This makes it possible to run the upcoming annotationparser.py tests with both Python 2 and Python 3. https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner: use dict.items()...Dieter Verfaillie2012-11-281-6/+5
| | | | | | | | | ... in favor of "for key in dict: value=dict[key]" and "dict.iteritems()". This makes it possible to run the upcoming annotationparser.py tests with both Python 2 and Python 3. https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner: use "if in [a, b]" instead of "if == a or if == b"Dieter Verfaillie2012-11-281-2/+2
| | | | | | It simply looks better... https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner: improve wording of inline documentationDieter Verfaillie2012-11-281-36/+57
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=688897
* annotationparser: cleanup and add tests for the new warnings we now emitDieter Verfaillie2012-04-171-30/+21
| | | | | | | | | Including: - handle things in the logical order encountered (first colon, then annotations) - correctly report column when missing a colon on the identifier part - small type fixes - remove no longer useful "parameter/tag expected" warnings
* Revert "annotationparser: indent _parse_comment_block gtkdoc code"Dieter Verfaillie2012-04-171-95/+95
| | | | | | | | | This reverts commit f41525d54f53edd9b0d665397f7c6c755ee3616b and adds a more complete solution as the original commit only handled empty lines between the GTK-Doc comment block start token "/**" and the identifier. https://bugzilla.gnome.org/show_bug.cgi?id=673806
* annotationparser: indent _parse_comment_block gtkdoc codeAlban Browaeys2012-04-171-89/+90
| | | | | | | | | | | | | | | | | | | | The current logic in _parse_comment_block of the annotationparser check the identifier and use variables that only makes sense if a result was returned (column_offset, original_line). This patch indent the logic so it is only triggered if a result is found. Otherwise it returns None as expected by call chain "parse > parse_comment_block > _parse_comment_block": ie in "parse": comment_block = self.parse_comment_block(comment) if comment_block is not None: This still raises a lot of warnings but does not abort while generating gir for libgnomekbd, mutter or telepathy-glib (those thus have to be tweaked not to call g-ir-scanner with --warn-error at least until the parser mask those false positives or the doc from those projects is fixed to comply with the behaviour expected by giscanner). https://bugzilla.gnome.org/show_bug.cgi?id=673806
* annotationparser: split validate() into sub-methodsWill Thompson2012-04-091-58/+67
| | | | | | | | Most cases in validate() were already simply calls to _validate_option() with particular arguments; this extracts the code from the remaining options to their own methods, making the dispatch table more legible. https://bugzilla.gnome.org/show_bug.cgi?id=670985
* annotationparser: correct "maximium" in error messagesWill Thompson2012-04-091-3/+3
| | | | | | | | "Maximium" is not an English word. Even if corrected to "maximum" (which is), "at maximum" is not conventional usage: "at most" is more idiomatic. https://bugzilla.gnome.org/show_bug.cgi?id=670985
* annotationparser: remove duplication of annotation namesWill Thompson2012-04-091-13/+13
| | | | | | | | | | Previously, the validation code compared each option name to a constant (such as OPT_ALLOW_NONE) which expands to the string used in a source file, and if they matched it would typically pass that same string to _validate_option(). But the annotation name was written out longhand each time, which seemed strange to me. https://bugzilla.gnome.org/show_bug.cgi?id=670985
* Split parameter and tag storage in annotationparser parse treeDieter Verfaillie2012-04-051-24/+32
| | | | | | | | | | | This avoids tags overwriting parameters if they happen to share the same name. For example, this was triggered by valid code in libgnome-keyring. tests/scanner/regress.c and tests/scanner/regress.h test written by Colin Walters <walters@verbum.org>. https://bugzilla.gnome.org/show_bug.cgi?id=672254
* Don't parse doc comments in dependenciesJohan Dahlin2012-04-051-0/+3
| | | | | Only parse doc comments for the files we pass in on the command line to g-ir-scanner, not the included dependencies.
* Replace ''' with """, to avoid confusing syntax highlightning in emacsJohan Dahlin2012-04-051-8/+8
|
* Now make AnnotationParser do what gobject-introspection needs it to do.Dieter Verfaillie2012-04-051-222/+443
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=672254
* Make AnnotationParser._parse_comment() do what gtk-doc does.Dieter Verfaillie2012-04-051-169/+226
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=672254
* Add a floating alias for noneJohan Dahlin2011-11-251-1/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=657202
* Add constant value annotationJohan Dahlin2011-09-141-1/+3
| | | | | Add an annotation tag "Value:" which can be used on constants to override the value.
* annotationparser: Don't eat lines that look like parameters outside param listColin Walters2011-08-141-4/+10
| | | | | | | | | If we're done parsing parameters, previously we would simply eat lines that looked like @foo: blah blah Example is in gtkcssprovider.c. https://bugzilla.gnome.org/show_bug.cgi?id=656504
* annotationparser: Only accept certain tagsColin Walters2011-08-131-3/+17
| | | | | | | | | | | Previously we were eating any line form "* [A-Za-z]: " as a tag, but this is a problem since e.g. gtk/gtk/gtkcssprovder.c had literal CSS e.g. block: which erroneously matched. Fix this by only accepting particular tags, similar to what gtk-doc does (although we accept a superset, e.g. transfer too). https://bugzilla.gnome.org/show_bug.cgi?id=656458
* scanner: Don't throw away blank lines in the docsColin Walters2011-08-131-3/+10
| | | | | | For generating documentation, we actually want to preserve these. https://bugzilla.gnome.org/show_bug.cgi?id=656389
* giscanner: Make comments starting with tab characters workJasper St. Pierre2011-07-221-3/+5
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=655149
* Add (method) overridesTomeu Vizoso2011-02-021-1/+5
| | | | | | So methods such as gtk_drag_dest_set() can be put inside Gtk.Widget https://bugzilla.gnome.org/show_bug.cgi?id=639945
* Preserve gtk-doc section namesJohan Dahlin2011-02-011-3/+9
| | | | | Preserve the section names and write them out on the class/record/ interface.
* Add (constructor) annotationTomeu Vizoso2011-01-281-1/+5
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=561264
* Accept trailing whitespace at the start of a comment blockColin Walters2010-10-191-5/+3
| | | | | | Might as well be liberal here, as long as we have a test case. https://bugzilla.gnome.org/show_bug.cgi?id=631690
* annotationparser: Don't ignore annotations if there's a : in docsGOBJECT_INTROSPECTION_0_9_8Colin Walters2010-09-281-1/+5
| | | | | | | | The annotation parser changed to be stricter about annotation content, but we introduced a regression where a : in the documentation would wrongly cause the annotation to be skipped. https://bugzilla.gnome.org/show_bug.cgi?id=630862
* [annotationparser] Extract (skip) for doc blocksJohan Dahlin2010-09-251-1/+8
|
* Print out line numbersJohan Dahlin2010-09-241-3/+7
| | | | | But disable the printing by default since it messes up the generated file. And fix a couple of typos
* Add a script to extract gio annotationsJohan Dahlin2010-09-241-2/+6
|
* Add an annotation toolJohan Dahlin2010-09-241-0/+52
|
* [annotationparser] Allow param less closuresJohan Dahlin2010-09-241-1/+5
| | | | | Allow closures without annotations to avoid having to duplicate the parameter name.
* Add more array warnings + testsJohan Dahlin2010-09-241-5/+25
|
* [annotationparser] Validate the rest of the annotationsJohan Dahlin2010-09-241-19/+87
| | | | | All option annotations, which uses parenthesis are now properly validated for number of values they expect
* Add a position to doc optionsJohan Dahlin2010-09-241-2/+8
|
* [annotation] Add constants for out optionsJohan Dahlin2010-09-241-0/+4
|
View Lorry Controller Status