summaryrefslogtreecommitdiff
path: root/giscanner/maintransformer.py
Commit message (Collapse)AuthorAgeFilesLines
* Improve getter function matching heuristicEmmanuele Bassi2021-08-051-8/+13
| | | | | | | Some readonly boolean properties in the form of 'has-foo' or 'is-bar' expose a getter function in the form of `get_has_foo()` or `get_is_bar()`, according to extant coding practices. We should ensure we still check for those.
* scanner: Warn if property annotations are mismatchedEmmanuele Bassi2021-08-051-14/+30
| | | | | | If the (set-property) and (get-property) annotations on methods do not round trip with the (setter) and (getter) annotations on the corresponding property, we want to emit a warning.
* scanner: Add an heuristic for property gettersEmmanuele Bassi2021-08-051-1/+6
| | | | | | | | If a property is boolean and read-only, the getter method can be the same as the property name, for instance: - gtk_widget_has_focus() - gtk_media_stream_has_audio()
* scanner: Try to pair properties with accessor methodsEmmanuele Bassi2021-08-051-0/+21
| | | | | | | The heuristic is pretty trivial: for any given non-construct-only, writable property, we check if there's a `set_<property>` method; for any given readable property, we check if there's a `get_<property>` method.
* Add annotations for property setters and gettersEmmanuele Bassi2021-08-051-2/+8
| | | | | We need new annotations to allow library developers to associate a setter and a getter functions to a property definition.
* Add new annotations for property accessorsEmmanuele Bassi2021-08-051-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We introduce two new annotations: - (set-property PROPERTY_NAME) - (get-property PROPERTY_NAME) These annotations are valid inside function blocks for methods on objects and interfaces, and define whether a function is a property accessor, e.g.: /** * gtk_widget_set_name: (set-property name) * @self: ... * @name: ... * * ... */ /** * gtk_widget_get_name: (get-property name) * @self: ... * * ... * * Returns: ... */ The annotations are transformed into the GIR data as attributes: - glib:set-property="PROPERTY_NAME" - glib:get-property="PROPERTY_NAME" The underlying typelib data has had flags for setter and getter functions for a while, but they have never been plugged into the GIR data or the introspection scanner. Now they are; you can retrieve the GIPropertyInfo from a GIFunctionInfo that has the GI_FUNCTION_IS_SETTER or GI_FUNCTION_IS_GETTER flags set. Fixes: #13
* Merge branch 'standalone-doc-sections' into 'master'Mathieu Duponchelle2020-07-221-1/+15
|\ | | | | | | | | Add the notion of standalone doc sections. See merge request GNOME/gobject-introspection!226
| * Add the notion of standalone doc sections.Mathieu Duponchelle2020-07-121-1/+15
| | | | | | | | | | | | | | | | 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.
* | giscanner: parse block comments for members and fieldsMathieu Duponchelle2020-07-121-17/+32
|/ | | | | | | | | | | | | | | | | | | | | | | | | | 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
* scanner: parse and expose function macrosMathieu Duponchelle2019-07-191-0/+12
| | | | | This is useful for documentation tools, and other utilities that rely on full introspection of the C API of a given library.
* maintransformer: Don't warn on (optional) annotations on (inout)Guido Günther2019-01-131-2/+3
| | | | This makes the scanner consistent with the docs.
* maintransformer: when the namespace is empty use error() instead of fatal()Christoph Reiter2019-01-101-1/+1
| | | | | | | | | | | 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.
* maintransformer: parse deprecation annotations for section blocks. Fixes #213Christoph Reiter2019-01-091-3/+1
| | | | | | | | | | 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.
* Drop all Python 2 compat codeChristoph Reiter2018-12-081-5/+0
| | | | We only support 3.4+ now.
* writer: Include documentation and symbol position in source filesThibault Saunier2018-11-281-0/+5
| | | | | | | | | | | 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
* tests: depend on flake8 instead of including pep8/pyflakesChristoph Reiter2018-08-151-3/+2
| | | | | | | | | | | | | | | | 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.
* Preserve complete C type when applying array annotations.Tomasz Miąsko2018-06-201-0/+1
|
* Use uint8 as default element type when constructing ByteArray.Tomasz Miąsko2018-04-151-8/+5
| | | | Fixes issue #184.
* giscanner: Fix minor python3 compatibility issueNirbheek Chauhan2018-03-101-1/+1
| | | | | | 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.
* Preserve complete_ctype when using type from annotation.Tomasz Miąsko2018-02-091-0/+1
| | | | | | | | 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.
* tests: Add more regression tests for (not nullable)Philip Withnall2015-11-061-0/+1
| | | | | | | | | | | | 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
* maintransformer: Fix regression in callback closure assignmentColin Walters2015-10-101-5/+6
| | | | | | | 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
* giscanner: Mark gpointer nodes as nullable by defaultPhilip Withnall2015-10-041-3/+17
| | | | | | | | | | | | | 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
* giscanner: Mark (closure) parameters as (nullable) by conventionPhilip Withnall2015-10-041-0/+7
| | | | | | | | 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
* scanner: Warn and ignore return annotations when there is no return valueGarrett Regier2015-10-041-1/+6
| | | | | | | | 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>
* scanner: Warn and ignore on incorrect optional/nullable/allow-none annotationsGarrett Regier2015-10-041-3/+18
| | | | | | | 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>
* scanner: Fix allow-none on return valuesGarrett Regier2015-09-291-1/+2
| | | | | | | | 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>
* scanner: Pacify PEP8Colin Walters2015-09-291-1/+1
|
* giscanner: Sort unknown parameters in error messageSimon Feltman2015-09-291-1/+2
| | | | | | | | | | 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
* giscanner: Use unicode literals in all Python filesSimon Feltman2015-09-291-0/+1
| | | | | | | | | | | | 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
* giscanner: Replace repr format usage with string formatterSimon Feltman2015-09-291-22/+22
| | | | | | | | | | | 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
* giscanner: Use print as a function for Python 3 compatibilitySimon Feltman2015-09-291-1/+2
| | | | | | | 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
* giscanner: Enable "true division" for all Python filesSimon Feltman2015-09-291-0/+1
| | | | | | | | | | 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
* giscanner: Use absolute_import for all Python filesSimon Feltman2015-09-291-0/+2
| | | | | | Use absolute_import to ensure Python 3 compatibility of the code base. https://bugzilla.gnome.org/show_bug.cgi?id=679438
* giscanner: Use items() instead of iteritems()Simon Feltman2015-09-291-4/+4
| | | | | | | Replace usage of iteritems() and itervalues() with items() and values() respectively. https://bugzilla.gnome.org/show_bug.cgi?id=679438
* scanner: Explicitly error with constructors but no GObject includeColin Walters2015-09-291-1/+5
| | | | | One of the Anaconda developers hit this; the fix was to include GObject, but without this commit we just traceback'd.
* scanner: GVariants are also valid to be floatingColin Walters2015-09-281-2/+3
| | | | More followup to https://bugzilla.gnome.org/show_bug.cgi?id=752047
* scanner: Tweak "invalid transfer" warning to show type tooColin Walters2015-09-271-6/+6
| | | | Should help debugging.
* scanner: Warn and ignore on incorrect transfer annotationsColin Walters2015-09-271-9/+59
| | | | This reverts commit 232f3c831260f596e36159112292897962a505b4.
* Revert "scanner: Warn and ignore on incorrect transfer annotations"Michael Catanzaro2015-09-271-59/+9
| | | | | | It broke at least atk and mutter. This reverts commit 5ae7bd58b6266997b61d897ad6562118eeb59210.
* scanner: Warn and ignore on incorrect transfer annotationsGarrett Regier2015-09-261-9/+59
| | | | | | | | 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>
* tests: Update misc/pep8.py to 1.6.2Dieter Verfaillie2015-06-291-4/+4
| | | | | Updated from: https://raw.githubusercontent.com/jcrocholl/pep8/1.6.2/pep8.py
* scanner: allow (array zero-terminated) instead of (array zero-terminated=1)Dieter Verfaillie2015-03-031-3/+7
| | | | | | | | | | | | | | 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
* scanner: Honor nested types on array declarations as wellColin Walters2014-09-051-1/+4
| | | | | | | | | 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
* giscanner: fix a comparisonRyan Lortie2014-05-061-1/+1
| | | | | | | | 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
* giscanner: add (nullable) and (optional) annotationsRyan Lortie2014-05-061-1/+7
| | | | | | | | | | | 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
* giscanner: change some internal field logicRyan Lortie2014-05-061-2/+5
| | | | | | | | | | | | | | | | | | 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
* giscanner: tweak GCancellable null special caseRyan Lortie2014-05-061-2/+3
| | | | | | | | | | | | | | 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
* maintransformer: split up a complex conditionalRyan Lortie2014-05-061-3/+5
| | | | | | | | | | | | 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
* giscanner: Use range instead of xrange for Python 3 compatibilitySimon Feltman2014-05-011-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=679438