| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
Add the notion of standalone doc sections.
See merge request GNOME/gobject-introspection!226
|
| |
| |
| |
| |
| |
| |
| |
| | |
Up to now, section annotations had to match a class or interface
name in order to be serialized in the gir.
With this commit, they now get serialized as docsection nodes,
for potential use by documentation tools.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was previously no mechanism for tagging enum members
and struct fields with Since tags (or other, eg deprecation tags).
While the customary place to add Since tags for these symbols
is inline in the parent symbol's documentation eg:
/**
* Foo:
*
* @FOO_BAR: some bar. Since X.Y
*/
And variations on that theme, implementing parsing for that scheme
would result in a pretty ambiguous grammar, especially if we also
want support for multiple tags.
Instead, the solution implemented here is to allow providing
documentation for individual members and fields through their
own separate block, as is done for virtual functions already.
Inline comments are still used, with a lower precedence.
Fixes #348
|
|
|
|
|
| |
This is useful for documentation tools, and other utilities that
rely on full introspection of the C API of a given library.
|
|
|
|
| |
This makes the scanner consistent with the docs.
|
|
|
|
|
|
|
|
|
|
|
| |
network-manager is calling things like this during configure:
g-ir-scanner --namespace=test --library=c /dev/null --output /dev/null
to test if the scanner is working. This results in a fatal error, but
beause of #229 was ignored.
Do keep this working after we fix #229 downgrade this to a simple recoverable
error message. An empty namespace doesn't prevent the scanner from creating
a .gir file so this should be fine.
|
|
|
|
|
|
|
|
|
|
| |
The scanner matches gtk-doc sections which match the lower case type name
to the type and uses that for the type documentation. The only problem is
it only takes the docs and none of the other annotations like deprecation
info etc.
This changes things to also parse the annotations in that case and adds some
tests while at it.
|
|
|
|
| |
We only support 3.4+ now.
|
|
|
|
|
|
|
|
|
|
|
| |
Some documentation tool (as hotdoc[0]) need to have information about
symbol declaration and documentation positions in the source files
to be able to do smart indexing (automatically build the documenation
index).
[0] https://hotdoc.github.io/
Fixes #175
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
g-i includes an old version of pep8 and pyflakes and uses that
during "make check".
It (1) doesn't catch all cases newer versions of pycodestyle/pyflakes catch
and (2) doesn't test all Python files (3) doesn't work with meson.
Instead of updating just remove them and depend on flake8 instead.
To run the checks simply run flake8 in the root dir.
This also makes it possible to run those checks when using meson and
not autotools.
To not get test suite failures on flake8 updates move the checks from
"make check" to an extra "make check.quality" target.
|
| |
|
|
|
|
| |
Fixes issue #184.
|
|
|
|
|
|
| |
dict.items() returns a tuple in Python2 but it returns an iterator in
Python3. This is usually fine, except that in this place we also try
to index the return value which won't work with iterators.
|
|
|
|
|
|
|
|
| |
When replacing type with one from user annotation we already preserve
ctype, do the same for complete_ctype to preserve const / volatile
qualifiers if any.
Fixes issue #190.
|
|
|
|
|
|
|
|
|
|
|
|
| |
On bug #719966, the question arose of whether parameters annotated with
(element-type) but not (not nullable) are regarded as nullable or
non-nullable.
Add some new unit tests to Regress-1.0.gir to check the behaviour is as
expected: annotating a parameter with (element-type) implicitly makes it
non-nullable (unless also annotated with (nullable)).
https://bugzilla.gnome.org/show_bug.cgi?id=757678
|
|
|
|
|
|
|
| |
The nullable code needs to search via index lookup of closure_name,
which drops the need to (incorrectly) assign closure_name again.
https://bugzilla.gnome.org/show_bug.cgi?id=756352
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gpointer parameters and return types should be marked as nullable by
default, unless:
• also annotated with (type) and not with (nullable); or
• explicitly annotated with (not nullable).
This introduces the (not nullable) annotation as a direct opposite to
(nullable). In future, (not) could be extended to invert other
annotations.
https://bugzilla.gnome.org/show_bug.cgi?id=729660
|
|
|
|
|
|
|
|
| |
All user_data pointers should be nullable, and they should all be
annotated as closures too. I have not found any counter-examples where a
closure is non-nullable.
https://bugzilla.gnome.org/show_bug.cgi?id=729660
|
|
|
|
|
|
|
|
| |
Otherwise the .gir can contain invalid data which would
likely cause a crash at runtime.
https://bugzilla.gnome.org/show_bug.cgi?id=752044
Signed-off-by: Garrett Regier <garrett.regier@riftio.com>
|
|
|
|
|
|
|
| |
These can easily be misunderstood, especially optional.
https://bugzilla.gnome.org/show_bug.cgi?id=752065
Signed-off-by: Garrett Regier <garrett.regier@riftio.com>
|
|
|
|
|
|
|
|
| |
The optional annotation was being applied which
is invalid for return values.
https://bugzilla.gnome.org/show_bug.cgi?id=752029
Signed-off-by: Garrett Regier <garrett.regier@riftio.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Sort the parameters displayed for the "unknown parameters"
error message. The parameter names are stored in a set which
returns a different ordering between Python 2 and 3
(set/dict ordering should not be relied upon anyhow).
This fixes test failures in warning tests.
https://bugzilla.gnome.org/show_bug.cgi?id=679438
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add unicode_literals future import which turns any string literal
into a unicode string. Return unicode strings from the Python C extension
module. Force writing of annotations (g-ir-annotation-tool) to output utf8
encoded data to stdout.
This is an initial pass at following the "unicode sandwich"
model of programming (http://nedbatchelder.com/text/unipain.html)
needed for supporting Python 3.
https://bugzilla.gnome.org/show_bug.cgi?id=679438
|
|
|
|
|
|
|
|
|
|
|
| |
Replace occurances of "%r" (repr) in format strings where the intended
behaviour is to output a quoted string "'foo'" with explicit usage
of "'%s'". This is needed to move the codebase to unicode literals
in order to upgrade to Python 3. Python 2 unicode strings are expanded
with repr formatting prefixed with a "u" as in "u'foo'" which causes
failures for various text formatting scenarios.
https://bugzilla.gnome.org/show_bug.cgi?id=679438
|
|
|
|
|
|
|
| |
Use future import "print_function" and update relevant uses of print
as a function call. See: PEP 3105
https://bugzilla.gnome.org/show_bug.cgi?id=679438
|
|
|
|
|
|
|
|
|
|
| |
Import Python 3 compatible "true division" from the future (PEP 238).
This changes the Python 2 classic division which uses floor division
on integers to true division. Verfied we don't actually use the
division operator anywhere in the code base so this a safety for
supporting both Python 2 and 3.
https://bugzilla.gnome.org/show_bug.cgi?id=679438
|
|
|
|
|
|
| |
Use absolute_import to ensure Python 3 compatibility of the code base.
https://bugzilla.gnome.org/show_bug.cgi?id=679438
|
|
|
|
|
|
|
| |
Replace usage of iteritems() and itervalues() with items() and values()
respectively.
https://bugzilla.gnome.org/show_bug.cgi?id=679438
|
|
|
|
|
| |
One of the Anaconda developers hit this; the fix was to include
GObject, but without this commit we just traceback'd.
|
|
|
|
| |
More followup to https://bugzilla.gnome.org/show_bug.cgi?id=752047
|
|
|
|
| |
Should help debugging.
|
|
|
|
| |
This reverts commit 232f3c831260f596e36159112292897962a505b4.
|
|
|
|
|
|
| |
It broke at least atk and mutter.
This reverts commit 5ae7bd58b6266997b61d897ad6562118eeb59210.
|
|
|
|
|
|
|
|
| |
This is an issue in various code bases and tends
to confuse newcomers.
https://bugzilla.gnome.org/show_bug.cgi?id=752047
Signed-off-by: Garrett Regier <garrett.regier@riftio.com>
|
|
|
|
|
| |
Updated from:
https://raw.githubusercontent.com/jcrocholl/pep8/1.6.2/pep8.py
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
What we already had:
- (array zero-terminated=1) > array which is NULL terminated
- (array zero-terminated=0) > array which is not NULL terminated
- (array) > array which is not NULL terminated
- (array zero-terminated=X) > array which is not NULL terminated
where X can be anything
What this patch adds:
- (array zero-terminated) > array which is NULL terminated
https://bugzilla.gnome.org/show_bug.cgi?id=657754
|
|
|
|
|
|
|
|
|
| |
We have special code to look at (type GLib.List(utf8)), but (type
GLib.PtrArray(utf8)) didn't work.
This allows NetworkManager to annotate the ActiveConnections property.
https://bugzilla.gnome.org/show_bug.cgi?id=733879
|
|
|
|
|
|
|
|
| |
In the case that a parameter has not been explicitly annotated, the
value of node.direction will be None, not 'in'. Instead of comparing as
== 'in' we should therefore check for being != 'out'.
https://bugzilla.gnome.org/show_bug.cgi?id=660879
|
|
|
|
|
|
|
|
|
|
|
| |
Add two new annotations, (nullable) and (optional).
(nullable) always means "the type of this value can also contain null".
(optional) always means "this out parameter can be ignored by passing
NULL to the C function".
https://bugzilla.gnome.org/show_bug.cgi?id=660879
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the 'allow_none' field on parameters with two separate fields:
'nullable' and 'optional'.
Currently, we use 'nullable' to mean the same thing as 'allow-none' for
normal (non-out) parameters. For out parameters, we use the 'optional'
field instead.
Note that the special case for GCancellable and GAsyncReadyCallback is
already guarded by a check for being an in parameter, so we always use
'nullable' here.
On the .gir writer side, we decide which variable to consult when
writing the allow-none attribute depending on the parameter direction.
https://bugzilla.gnome.org/show_bug.cgi?id=660879
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We treat GCancellable and GAsyncReadyCallback as if they were always
tagged (allow-none) because these parameters universally allow %NULL to
be given as a value when they appear as in parameters on functions.
Unfortunately, the meaning of (allow-none) is different on out
parameters. There it means that you can give %NULL to ignore the return
value.
Limit this special case to only in parameters.
https://bugzilla.gnome.org/show_bug.cgi?id=660879
|
|
|
|
|
|
|
|
|
|
|
|
| |
We assign node.allow_none in two separate cases:
- if the (allow-none) annotation was given
- for GCancellable and GAsyncReadyCallback, as special cases
Split the two up. This will simplify future commits.
https://bugzilla.gnome.org/show_bug.cgi?id=660879
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=679438
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=679438
|
|
|
|
|
|
|
|
|
|
|
| |
a final underscore
In cases like g_resources_register() and gdk_events_get_angle(),
the c_symbol_prefix of the first parameter (resp. g_resource and
gdk_event) is a prefix of the symbol, but the next character is
not _, so that should not be considered a method.
For backward compatibility reasons, we still generate one, but
then it's not included in the documentation (because of moved_to)
|
|
|
|
|
|
|
|
|
|
| |
The field of a callback need not be anonymous, it could be a
typedef, with a proper Type node.
Fixes TelepathyGlib.BaseClient having no virtual functions
(and probably others)
https://bugzilla.gnome.org/show_bug.cgi?id=723439
|
|
|
|
|
|
|
|
| |
I'd like to be able to use this inside GTK+.
See: https://bugzilla.gnome.org/show_bug.cgi?id=711153
https://bugzilla.gnome.org/show_bug.cgi?id=711157
|
|
|
|
|
|
| |
Structure field documentation was not being included in the gir file.
https://bugzilla.gnome.org/show_bug.cgi?id=710562
|
|
|
|
|
|
|
|
| |
A hidden exception was being thrown (which we now log), due to fields
being treated as function parameters. Fixed to make field array
annotations be transformed and written out to the gir correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=710561
|