| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update both test_parser.py and test_patterns.py to dynamically generate
TestCase sub-classes rather than modify a statically defined one.
Use unittest.TestSuite to queue up the generated test cases via the
"load_tests" hook.
Use underscores instead of periods as a seperator for dynamically generated
test cases and methods to match Python identifiers.
Beyond general cleanup, these changes will help the ability to specify
Python tests individually.
https://bugzilla.gnome.org/show_bug.cgi?id=720713
|
|
|
|
|
|
|
|
|
|
|
| |
When encountering /**/ in the source, parse_gtk_doc_comment()
would be executed (due to the /** part starting a GTK-Doc
comment block) and would happily consume the / and everything
up until the next comment block was closed or EOF, thus
consuming a whole block of C code...
Encoutered in the wild here:
https://git.gnome.org/browse/clutter-gst/tree/clutter-gst/clutter-gst-player.c?id=03f0d8f48bd7f60e582e6185cb73a07038e8d55d#n1926
|
|
|
|
|
|
| |
Makes our GTK-Doc comment block rewriting tool halt on
such issues, requireing user intervention instead of writing
back even more bogus data.
|
| |
|
|
|
|
|
|
|
|
|
| |
GTK-Doc parameter description fields are allowed to span
multiple lines, tag description fields are allowed to span
multiple lines and paragraphs. A tool fixing/rewriting
GTK-Doc comment blocks in source files would need to have
description fields parsed and stored (almost) exactly as
they appear in the source file.
|
| |
|
|
|
|
|
|
| |
so we can later use them to re-write source files containing
broken GTK-Doc comment blocks where /** is preceded by and/or
*/ is followed by code...
|
|
|
|
|
|
|
|
|
|
| |
- remove annotations regex, restore proper parens parsing
- drop weird DocOption() storage class and use lists/dicts
as appropriate
- make GtkDocAnnotations a simple OrderedDict subclass instead
of a weird hybrid dict/list storage class
- Deprecate Attribute: tag, replace with (attributes) annotation
on the identifier
|
| |
|
| |
|
|
|
|
|
|
|
| |
It serves as a GTK-Doc "field" separator, so delimiter seems
like a better name. This also makes the distinction between the
colon used in property/signal names (which is not a "field"
separator) and the GTK-Doc "field" separator a bit more clear.
|
| |
|
|
|
|
|
|
| |
We don't know how many apps do this, but at least ibus had one.
https://bugzilla.gnome.org/show_bug.cgi?id=689354
|
|
|
|
|
|
|
|
| |
... 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
|
|
... to tests/scanner/annotationparser/test_patterns.py because the
following patch will remove giscanner/annotationpatters.py
https://bugzilla.gnome.org/show_bug.cgi?id=688897
|