summaryrefslogtreecommitdiff
path: root/tests/scanner
Commit message (Collapse)AuthorAgeFilesLines
* tests: Use the appropriate assertion methodEmmanuele Bassi2023-01-081-53/+55
| | | | | | - assertEqual(value, None) → assertIsNone(value) - assertTrue(value is not None) → assertIsNotNone(value) - assertTrue(isinstance(value, Type)) → assertIsInstance(value, Type)
* Split disguised attribute into twoEmmanuele Bassi2023-01-085-6/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The disguised attribute started off as a way to indicate a typedef to a structure pointer, e.g. typedef struct Foo* FooPtr; Over the years, though, it started to include opaque structure types, e.g. typedef struct _FooObject FooObject; typedef struct _FooObjectClass FooObjectClass; This has led to issues in language bindings, code generators, and documentation generators, which now have issues when dealing with both pointer aliases and opaque types. An initial attempt at fixing this mess in commit f606183a ended up breaking Vala, and had to be reverted. To avoid breaking existing users we can follow a similar approach to the allow-none/nullable/optional solution: 1. introduce a new pair of attributes: "pointer" and "opaque" 2. deprecate the "disguised" attribute The "pointer" attribute covers the case of pointer types. The "opaque" attribute covers the case of opaque structured types. See also: https://gitlab.gnome.org/GNOME/vala/-/issues/735 Fixes: #101
* Revert "scanner: don't accept invalid symbols in binary expressions"Emmanuele Bassi2023-01-084-0/+48
| | | | This reverts commit b37f24b7e27a77c398f41cc331608aff806f0d42.
* test: Add regression test for the new tagsEmmanuele Bassi2023-01-085-229/+247
|
* Add `default-value` annotationEmmanuele Bassi2023-01-082-7/+13
| | | | | | | An escape hatch to specify a freeform string for the default value of a property. Fixes: #4
* Skip default-value for non-transformable propertiesEmmanuele Bassi2023-01-081-34/+11
| | | | | | | If we can't transform a property default value to string, we are not going to add a default-value attribute to the GIR. This is necessary because non-transformable values may not always be pointers, so we cannot default to "NULL".
* Add an optional attribute for the property default valueEmmanuele Bassi2023-01-081-23/+64
| | | | | | | | | The default-value attribute for a property element is fundamentally meant for documentation generators. We only care about the GIR data, as the conversion from the default value to a string is lossy by definition, and may very well not roundtrip.
* scanner: don't accept invalid symbols in binary expressionsLubomir Rintel2023-01-084-48/+0
| | | | | | | | | | | | | | | | | | | | | The rules for binary expressions were entirely oblivious to the type of the operand symbols and assumed they're integer constants. This is very unfortunate, since it caused all sort of nonsense to end up getting accepted. One such example is the following define from NetworkManager's libnm: #define NM_SETTING_PARAM_SECRET (1 << (2 + G_PARAM_USER_SHIFT)) As G_PARAM_USER_SHIFT is unknown, it was parsed as an invalid symbol. The addition didn't care, treated it as: #define NM_SETTING_PARAM_SECRET (1 << (2 + 0)) Let's just ensure we get CSYMBOL_TYPE_CONST only when both operands actually have const_int_set. Otherwise just create CSYMBOL_TYPE_INVALID. That will cause the symbol to be dropped on the floor eventually, but that's probably much better than a having an invalid value.
* tests/scanner: add some tests for #definesLubomir Rintel2023-01-088-239/+337
| | | | | | | | Add one expanding to an expression we can't get a constant value from and another one for which we can. Note that the bad on one currently does evaluate, and it does so to a bad value. A separate commit with a diff to test suite will address that.
* Add missing (void) arguments to comply with -Wstrict-prototypesMarco Trevisan (Treviño)2022-10-061-1/+1
|
* build: Add run_command() argumentEmmanuele Bassi2022-07-131-1/+1
| | | | The `check` argument to `run_command()` is now mandatory.
* Revert "scanner: Mark colliding properties as not introspectable"Emmanuele Bassi2022-02-133-1/+36
| | | | | | | | | This reverts commit 8e85d1ca937c166f07675d02fc84abb27d06ae11. Marking colliding properties as not introspectable breaks a bunch of existing API when compiling the GIR into the typelib, so we'll have to find another solution during the grace period.
* scanner: Mark colliding properties as not introspectableEmmanuele Bassi2022-02-123-36/+1
| | | | | We prefer methods, signals, and virtual methods to properties, in case of a collision.
* regress: Add a function to enable conversion between different fundamentalMarco Trevisan (Treviño)2022-01-114-147/+184
| | | | | We want to be able to test whether it's possible to convert two different fundamental types through GValue, so add a function for this.
* Regress: Add further subtype of fundamental with no set/get functionsMarco Trevisan (Treviño)2022-01-114-151/+242
| | | | | This can be used to test we don't do unexpected conversions between invalid types.
* regress: Add Fundamental type with no set/get-value-func'sMarco Trevisan (Treviño)2022-01-1126-149/+1184
| | | | | | | | | | A fundamental type may or may not provide set and get value functions, the regress implementations always provide one, so define a new type with no such functions so that we can test this case in Gjs. To avoid repeating lots of duplicated code, we re-use the same functions of RegressTestFundamentalObject when possible, by using the same structure.
* build: Avoid the doctemplates hackEmmanuele Bassi2022-01-111-11/+13
| | | | | | | | | | | | The hack that copies the doctemplates directory into the build directory has stopped working with newer versions of Meson; while it's possible to copy files, custom_target() cannot depend on a directory. Additionally, the dependency has always been broken. Instead, we enumerate the template files—after all, it's not like they change a lot—and then we list them as dependencies for the test targets. Fixes: #414
* scanner: Warn if property annotations are mismatchedEmmanuele Bassi2021-08-051-3/+7
| | | | | | 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: Try to pair properties with accessor methodsEmmanuele Bassi2021-08-051-2/+9
| | | | | | | 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.
* tests: Add a Regress test for the property accessors annotationsEmmanuele Bassi2021-08-052-5/+9
|
* tests: Check new property accessors annotationsEmmanuele Bassi2021-08-0510-275/+579
| | | | Add an accessors pair to Regress.TestObj and annotate them.
* Add glib:name to enum memberMarc-André Lureau2021-06-201-28/+56
| | | | | | | This member will contain the string from the GEnumValue/GFlagsValue 'value_name' introspection dump. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
* scanner: fix enum member c:identifierMarc-André Lureau2021-06-201-3/+3
| | | | | | Don't rely on runtime name, but on C header parsed symbol. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
* Make test suite work with cross-related optionsJohn Ericson2021-05-231-24/+16
| | | | | | | | | | Because of skepticism I received in #224, I made this PR which keeps the testsuite and CI improvements but doesn't add any new build options. I hope this would be less controversial: - no new knobs - tests for those using existing build options - CI tests `build_introspection_data = false`
* tests: Update line numbers for expected Regress GIREmmanuele Bassi2021-03-121-8/+8
|
* Use g_memdup2() with newer versions of GLibEmmanuele Bassi2021-03-121-0/+20
| | | | | The g_memdup() function has been deprecated, so we should use the new g_memdup2() function if available.
* Always pass an encoding to open() using text modeChristoph Reiter2020-11-072-2/+2
| | | | | | | | Otherwise we'll end up using the locale encoding. While it's usually utf-8, that's not the case on Windows. There is one place where a file with filenames is passed, not sure there so I left it and passed a explicit None.
* Revert "giscanner: Fix section matching for documentation"Mathieu Duponchelle2020-09-291-34/+0
| | | | | | | | | This reverts commit de6512b31b614567bf1800406303d1ccfb6d9455. This was causing naming conflicts when the SECTION documentation was picked over the class documentation. See https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/360
* giscanner: Fix section matching for documentationJames Westman2020-09-071-0/+34
| | | | | | | | | | | | | When writing documentation to the GIR files, GIR tries to match classes with their matching SECTION: comment in the source code. Some codebases use kebab-case or CamelCase for their section names, but GIR always expects them to be flatcase or the matching will fail. This commit converts all section names to flatcase (by removing "-" and converting to lowercase) while they are being parsed, so that they are matched properly later on. Fixes #350.
* Merge branch 'standalone-doc-sections' into 'master'Mathieu Duponchelle2020-07-226-26/+87
|\ | | | | | | | | Add the notion of standalone doc sections. See merge request GNOME/gobject-introspection!226
| * Add the notion of standalone doc sections.Mathieu Duponchelle2020-07-126-26/+87
| | | | | | | | | | | | | | | | 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-128-76/+155
|/ | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Meson: Fix build as subprojectXavier Claessens2020-05-061-20/+20
| | | | | meson.build_root() is the root of the main project, better use meson.current_build_dir() instead.
* Revert "Add support for element-type to GListModel"Rico Tzschichholz2020-04-2810-259/+0
| | | | | | Breaks vapigen and changes GListModel definition in Gio-2.0.gir This reverts commit a9f45431684e6be3623e272e54d481e4c5d9423d.
* Add support for element-type to GListModelEmmanuele Bassi2020-04-2610-0/+259
| | | | | | | | GListModel is an interface for creating typed, list-like containers. The data stored is GObject instances, but it's useful to be able to annotate the actual type, for both documentation and code generation purposes. The annotation should be optional, to maintain backward compatibility.
* Revert "Add element-type support to GListModel"Emmanuele Bassi2020-04-268-196/+0
| | | | | | This reverts commit b4c058bba4d95ae10e1e4238f9417fe954f97795. See: #336
* Revert "Generate appropriate docs for ListModel with element-type"Emmanuele Bassi2020-04-262-4/+4
| | | | | | This reverts commit ffe3e435e0b7943a0872034223b5f6ea02258ffa. See: #336
* Generate appropriate docs for ListModel with element-typeEmmanuele Bassi2020-04-242-4/+4
| | | | | | We need to special case the ListModel container type in the documentation writer so that we don't fall back into array/list automatic conversion in the code snippets.
* Add element-type support to GListModelEmmanuele Bassi2020-04-248-0/+196
| | | | | | | | GListModel is an interface for creating typed, list-like containers. The data stored is GObject instances, but it's useful to be able to annotate the actual type, for both documentation and code generation purposes. Fixes: #328
* Support the gtk-doc action syntaxEmmanuele Bassi2020-04-241-1/+153
| | | | | | | | | | | | | | | | GTK4 allows adding widget-related actions to the documentation with the newly defined syntax: <class_name> '|' <action_name> ':' This means g-ir-scanner needs to detect this new format, to avoid emitting unnecessary warnings. Currently, we don't do anything with the actions; in the future we might want to add them to the documentation in the GIR, but for that we'd need a new element. See also: GNOME/gtk-doc!30
* Fix regress scanner testsChun-wei Fan2020-02-062-5/+5
| | | | | | | | | There is no way that non-GCC/CLang compilers will pass this test because the source position will never match the position that is in tests/scanner/Regress-1.0-expected.gir. Fix this the fast way: define a macro according to the compiler check and update the corresponding source position
* test_scanner.py: Fix path tests on WindowsChun-wei Fan2020-01-161-2/+3
| | | | | | We may get drive letters and paths either in upper or lower cases in Windows, which are actually no different. Ignore the cases in this case.
* Visual Studio builds: Use -utf-8 where availableChun-wei Fan2020-01-151-0/+11
| | | | | | | | | | | | This avoids compilation erroring out on C4819 (Unicode handling issue in the Visual Studio compiler), notably when running on Chinese, Japanese and Korean (CJK) locales. This also applies -utf-8 into the cflags passed into the various g-ir-scanner command lines that are used to generate the *.gir files, where -utf-8 is available, so that we don't get flooded with C4819 warnings during the build, and therefore avoid potential mishaps, as C4819 is a real warning that warngs us the code may be incorrectly built.
* meson: change "doctool" from a boolean to a feature optionChristoph Reiter2019-09-301-1/+1
| | | | | | | Similar to !180 this should prevent devs from not running all tests by accident. This also adds some checks for the required doctool dependencies, mako and markdown.
* meson: change "cairo" from a boolean to a feature optionChristoph Reiter2019-09-281-7/+7
| | | | | | | | | We require cairo only to run all tests and thus default it to false. This usually results in developers not using it when working on changes and tests depending on cairo then failing in CI. This changes it to a feature option that defaults to auto, so that devs that have cairo headers installed will automatically use it.
* Support array arguments with static keywordEmmanuele Bassi2019-09-157-303/+455
| | | | | | | | | | | | | | | | | | | | | | | C99 allows defining an array argument with a fixed size as: void foo (int arr[static 10]) Compilers conforming to the C99 specification will be able to warn if the function is called with NULL or with an array smaller than the specified length, something that does not happen when using pre-C99 declarations like: void foo (int arr[10]) As the declaration above is identical to: void foo (int arr[]) Which is, in turn, identical to: void foo (int *arr) Fixes: #309
* tests: Don't include "config.h" in installed filesPhilip Chimento2019-08-158-163/+181
| | | | | | These tests get installed, so config.h may not be available. Do the same thing that gimarshallingtests.c and regress.c already do, and include config.h conditionally.
* ccompiler: use the distutils linker in the dumperChristoph Reiter2019-08-081-0/+5
| | | | | No need to hardcode things since distutils looks it up. Similar to !170 but for Windows.
* regress: Add regression test for signal with GError paramPhilip Chimento2019-08-0113-283/+701
| | | | | | | | This exercises the little-used code path where a signal is emitted with a nullable GError as a parameter. It's modeled after GstPbutils.Discoverer's 'discovered' signal. See GNOME/gjs#262.
* transformer: only include function macros from headers. See #159Christoph Reiter2019-07-223-46/+0
| | | | | We already do the same thing for constants (see _create_const()). Otherwise macros in .c files which aren't namespaced will trigger a warning.
View Lorry Controller Status