summaryrefslogtreecommitdiff
path: root/giscanner/annotationparser.py
Commit message (Collapse)AuthorAgeFilesLines
...
* giscanner: reindent re documentationDieter Verfaillie2013-10-081-101/+101
|
* giscanner: improve inline docsDieter Verfaillie2013-10-081-23/+106
|
* tests: Update misc/pep8.py to 1.4.6Dieter Verfaillie2013-10-081-28/+19
| | | | | Updated from: https://raw.github.com/jcrocholl/pep8/1.4.6/pep8.py
* tests: Update misc/pep8.py to 1.4.5Dieter Verfaillie2013-05-071-27/+38
| | | | | | | | | | | | | | | | | Version in our tree is a wee bit outdated. For example, later work will introduce an utf8 encoded python source file which our old pep8.py does not yet understand (yeah, it really was *that* ancient)... Updated from: https://raw.github.com/jcrocholl/pep8/1.4.5/pep8.py Takes 552c1f1525e37a30376790151c1ba437776682c5, f941537d1c0a40f0906490ed160db6c79af572d3, 5a4afe2a77d0ff7d9fea13dd93c3304a6ca993de and a17f157e19bd6792c00321c8020dca5e5a281f45 into account... https://bugzilla.gnome.org/show_bug.cgi?id=699535
* annotationparser: Remove get_tag/get_paramJasper St. Pierre2013-05-071-6/+0
| | | | | | They're useless if we can just access the dict directly. https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner: move odict.OrderedDict into a collections packageDieter Verfaillie2013-05-071-1/+1
| | | | | | because we'll add more related code to collections later on https://bugzilla.gnome.org/show_bug.cgi?id=699536
* giscanner: use SqlAlchemy's OrderedDict implementationDieter Verfaillie2013-04-091-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | g-ir-scanner can be a bit on the slow side. While true we now do a bit more work parsing GTK-Doc comment blocks and more is still to come, one of the biggest hotspots besides what's going on in _giscanner.SourceScanner() comes from the OrderedDict implementations we have been using. For example, time needed to build Gtk-3.0.gir on a relatively slow machine using "python2 -m cProfile -o $prefix/bin/g-ir-scanner ...": 1) Our original DictMixin sublass: 92,79867 seconds 2) Python's collections.OrderedDict class: 88,65786 seconds 3) Larosa/Foord implementation from http://www.voidspace.org.uk/python/odict.html : 71,64323 seconds 4) SqlAlchemy's implementation: 66,12449 seconds Looks like we have a clear winner with the SqlAclchemy implementation, which comes in at around 20 seconds without profiling on the same machine. Not bad. https://bugzilla.gnome.org/show_bug.cgi?id=697620
* giscanner: fix string formatting tuplesDieter Verfaillie2013-04-091-10/+10
| | | | | | | | | | | | | | | | | | | | During review Colin Walters mentioned: """ One thing I should probably explain is my habit of *always* passing a tuple for %. The reason is pretty simple...a long time ago I had an error handler that did: print "unexpected data: %s" % foo. And I'd changed the type of "foo" from a string to a tuple at some point. But this obviously caused "print" to fail because it was expecting multiple format strings. Basically always using tuples is safer in case you change the type of a variable to a tuple. """ This fixes violations of this rule introduced up until now. https://bugzilla.gnome.org/show_bug.cgi?id=697614
* 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
|
View Lorry Controller Status