summaryrefslogtreecommitdiff
path: root/giscanner
Commit message (Collapse)AuthorAgeFilesLines
* Split disguised attribute into twoEmmanuele Bassi2023-01-085-12/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-083-41/+36
| | | | This reverts commit b37f24b7e27a77c398f41cc331608aff806f0d42.
* Add copy and free function annotations for POD typesEmmanuele Bassi2023-01-085-5/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Plain Old Data (POD) types with or without a representation in the GType type system can still have a copy and/or a free function. We should allow annotating these types with their corresponding functions for copying their data into a new instance, and freeing their data. From a language bindings perspective, POD types should have a boxed GType wrapper around them, so they can use the generic GBoxed API to copy and free instances; from a documentation perspective, though, it'd be good to have a way to match a structured type, like a struct or a union, with its copy and free functions. In order to do that, we add two new header block annotations: - (copy-func function_name) - (free-func function_name) These annotations work exactly like ref-func and unref-func for typed instances: /** * GdkRGBA: (copy-func gdk_rgba_copy) * (free-func gdk_rgba_free) * @red: ... * @green: ... * @blue: ... * @alpha: ... * * ... */ The function is stored in the GIR data as two new attributes for the `<record>` and `<union>` elements: <record name="RGBA" c:type="GdkRGBA" copy-function="gdk_rgba_copy" free-function="gdk_rgba_free" glib:type-name="GdkRGBA" glib:get-type="gdk_rgba_get_type" c:symbol-prefix="gdk_rgba"> The annotations are not mandatory. See: #14
* Add `default-value` annotationEmmanuele Bassi2023-01-082-0/+20
| | | | | | | 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-1/+1
| | | | | | | 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-084-2/+9
| | | | | | | | | 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-083-36/+41
| | | | | | | | | | | | | | | | | | | | | 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.
* scanner: Ignore unused typing importEmmanuele Bassi2023-01-081-2/+2
| | | | | Ignore the typing import so that flake8 doesn't complain, and mypy keeps working.
* giscanner: undef "GLIB_VERSION_{MAX_ALLOWED,MIN_REQUIRED}" macros in ↵Thomas Haller2022-09-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | generated C file When g-ir-scanner is used by another project, than that project might have the GLIB_VERSION_* macros defined. This is useful to ensure that only intended glib API is used. The project might then also pass the CFLAGS to g-ir-scanner, without filtering those defines out. This can lead to compiler warnings. For example, NetworkManager sets the version macros to GLIB_VERSION_2_40 and thus gets these warnings /NetworkManager/tmp-introspect66917zc4/NM-1.0.c: In function ‘dump_object_type’: /NetworkManager/tmp-introspect66917zc4/NM-1.0.c:252:13: warning: Not available before 2.70 252 | if (G_TYPE_IS_FINAL (type)) | ^~~~~~~~~~~~~~~~~ /NetworkManager/tmp-introspect66917zc4/NM-1.0.c: In function ‘dump_fundamental_type’: /NetworkManager/tmp-introspect66917zc4/NM-1.0.c:370:13: warning: Not available before 2.70 370 | if (G_TYPE_IS_FINAL (type)) | ^~~~~~~~~~~~~~~~~ But these warnings are not correct. The installed g-ir-scanner knows for which glib version to generate code. Undefine the macros to avoid the warning.
* doctool: prepend the emitting object for GJS signal callbacksAndy Holmes2022-08-314-3/+16
|
* giscanner: Support C99 designated initializersJan Tojnar2022-08-171-2/+17
| | | | | | https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html Based on https://github.com/katef/kgt/blob/c9d8ad246855c6b65e42371be7898f4073c28d18/examples/c99-grammar.iso-ebnf#L247-L252
* build: disable some clang warnings for code not under our controlChristoph Reiter2022-07-191-0/+1
| | | | | cmph is vendored and other one is bison/flex generated code. Not much we can do here, so disable those warnings there.
* resolve_windows_libs: add llvm/mingw supportChristoph Reiter2022-07-191-10/+38
| | | | | | | | | | | | | | | | | | | | The existing code tries to mirror how the linker finds DLLs by searching for the import libs and then looking for the matching shared lib name. While llvm has a dlltool clone it doesn't provide the --identify option to extract the shared lib name. Instead we use the fact that llvm import libs include the dll name in the archive member name, so we can use "nm" there to get the same result. To decide which strategy to use we run dlltool and check if it contains "llvm-dlltool" in the output. This fixes the .gir and .typelib files containing bogus values for the shared library names when building with clang + mingw-w64 on Windows. I'm not quite sure if the libtool part is actually needed there, but I left it in to keep the diff small.
* Disable rpath handling on WindowsChristoph Reiter2022-07-191-1/+1
| | | | | | | While gcc on Windows allows being passed -rpath and just ignores it, llvm/lld will fail with "lld: error: unknown argument: -rpath". There is no such thing as rpath on Windows, so just skip it.
* giscanner: Support ISO varargs in function macrosPhilip Withnall2022-03-221-1/+22
| | | | | | This fixes support for macros like `g_message()` in GLib. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
* giscanner: Support function macros with zero argumentsPhilip Withnall2022-03-221-0/+10
| | | | | | | This fixes support for macros like `G_BREAKPOINT()` or `G_DEBUG_HERE()` in GLib. Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
* scanner: Check before accessing an optional fieldEmmanuele Bassi2022-03-181-1/+2
| | | | | | | | | It seems that optparse might just ignore storing options without a default. In this case, the `--compiler` option should be initialised to `None`, but instead it just gets ignored. Without the `hasattr()` check, updating the introspection data for GLib fails with a Python backtrace.
* scannerparser.y: Include io.h on WindowsChun-wei Fan2022-02-131-0/+4
| | | | | We need it for close(), especially when unistd.h is not available, such as in the case of Visual Studio-style builds.
* Revert "scanner: Mark colliding properties as not introspectable"Emmanuele Bassi2022-02-131-3/+0
| | | | | | | | | 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.
* Add --compiler argument to g-ir-scannerEmmanuele Bassi2022-02-123-5/+13
| | | | | | | | | | | | We currently use the `CC` environment variable to find the C compiler to use internally in g-ir-scanner. Build systems might wish to store the compiler detected during the build configuration, and then pass that compiler to g-ir-scanner at the time of build, avoiding to put things into the environment. One possible solution is to have a command line argument that lets us specify the C compiler, with the same semantics as the `CC` environment variable.
* scanner: Validate emitter methodsEmmanuele Bassi2022-02-121-0/+35
| | | | | | | | | Follow the same semantics as Vala: 1. emitters should have the same return value as the signal 2. emitters should have the same parameters as the signal they emit (minus the instance parameter, which is implied in signals)
* scanner: Add (emitter) annotation for signalsEmmanuele Bassi2022-02-125-10/+67
| | | | | | Signals that have an emitter function should have an annotation to allow consumers of the introspection XML to effectively pair signals to their corresponding emitter functions that share the same prototype.
* scanner: Fix strict log node emitterEmmanuele Bassi2022-02-121-1/+1
| | | | We need to use log_node(), not a plain log().
* scanner: Mark colliding properties as not introspectableEmmanuele Bassi2022-02-121-0/+3
| | | | | We prefer methods, signals, and virtual methods to properties, in case of a collision.
* scanner: Use strict_node() for property name collisionEmmanuele Bassi2022-02-121-1/+1
| | | | | This way we only raise a warning when operating under the newly added strict mode.
* scanner: Add strict modeEmmanuele Bassi2022-02-122-1/+25
| | | | | | | | | To avoid introducing additional strictness onto unsuspecting libraries, we introduce a new mode: "strict". The strict mode is opt-in, and used to signal potential issues with the public API once exposed by language bindings, even when it's fully introspectable.
* Handle property name collisionsEmmanuele Bassi2022-02-121-0/+41
| | | | | | | | | | | Properties cannot have the same name as signals, methods, and virtual functions, as they will break various language bindings. Since listing this requirement only in the documentation has been insufficient, we should emit a warning, and hope that library developers will pay attention to it. Fixes: #386
* Use binary mode buffer for stdout Hu Jialun2022-02-021-1/+1
| | | | | By default, stdout is in text mode, expecting a str rather than byte. Change the output destination to the underlying binary buffer to write bytes.
* CI: use a newer mypy in CI to fix the msys2 jobChristoph Reiter2022-02-021-4/+8
| | | | | | | | | | | | | MSYS2 recently updated Python to 3.9.10 which triggered a build issued present in typed_ast, which was fixed in typed_ast 1.5.0: https://github.com/python/typed_ast/issues/169 The currently used mypy version has an upper limit on typed_ast, so this fixed version wasn't pulled in. To fix this, update mypy, fix one new warning it complains about (namedtuple not being named after the variable), and install the markdown stubs explicitely, since mypy no longer bundles them.
* windows: fix build using subprojects with python >=3.8Andoni Morales Alastruey2022-01-282-10/+41
| | | | Fixes #416
* build: Avoid the doctemplates hackEmmanuele Bassi2022-01-113-11/+85
| | | | | | | | | | | | 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
* doctool: Add templates_dir CLI argumentEmmanuele Bassi2022-01-112-7/+11
| | | | | | We can find the templates directory using the module file once installed, but when running uninstalled we need to have a way to specify where the templates can be found in the sources directory.
* Add "forever" scopeEmmanuele Bassi2022-01-093-2/+5
| | | | | | | | Some functions are meant to exist for the entire duration of the process, and thus have no need for a notification function because one will never be called. Fixes: #49
* docwriter.py: change DocFormatterGjs to return Uint8ArrayAndy Holmes2021-11-231-1/+1
| | | | | | GJS now maps GLib.ByteArray and GLib.Bytes to Uint8Array whenever possible. Change the string returned by docwriter for devdocs to reflect that.
* giscanner.ast: map uintptr_t and intptr_tMarc-André Lureau2021-10-281-0/+2
| | | | | | | | | Those types should map by definition to guintptr and gintptr. They are fairly common in Rust cbindgen projects, which maps usize->uintptr_t for ex. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
* scanner: Handle constructors with mismatched GTypesEmmanuele Bassi2021-08-161-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For historical reasons, we have boxed types that do not follow the typical conversion from CamelCase to snake_case when it comes to their get_type function. The introspection scanner will correctly detect that a type is matched to that get_type function, but then it will default to tokenize the get_type function to set the c_symbol_prefix of the given type. The method pairing code in the main transformation path takes that mismatch into consideration, but the constructor pairing code does not. This leads to interesting cases, like GString. GString is correctly detected as GLib.String, and correctly matched to its `g_gstring_get_type()` type function, but its c_symbol_prefix is set to `gstring` after the tokenization. While methods like `g_string_append()` are correctly paired to the `GLib.String` node, constructors like `g_string_new()` do not, and end up being turned into function nodes, like `GLib.string_new`, even if they are annotated as constructors. I'm not entirely confident that changing the c_symbol_prefix tokenization this late in the game is going to be free of regressions; instead, we provide a way for pairing constructors if they are annotated as such. In other words: non-annotated constructors of types that have a different symbol prefix than the one of the get_type function will stay as they are today—a global function. To enforce the matching, we rely on an explicit `(constructor)` annotation; at least, this should ensure that we have explicit buy in from the maintainers of the API. Fixes: #399
* Ignore accessor annotations for non-introspectable propertiesEmmanuele Bassi2021-08-052-3/+29
| | | | | | | If a property is not introspectable we need to decouple it from its accessors; the property data will not be compiled into the typelib, and when the compiler will try to resolve the offsets into the binary blob we'll get a fatal exception.
* 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-055-7/+65
| | | | | 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-055-7/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add "final" class attributeEmmanuele Bassi2021-08-054-3/+14
| | | | | | | | A "final" class is a leaf node in a derivable type hierarchy, and cannot be derived any further. This matches the changes in libgobject that introduced G_TYPE_FLAG_FINAL to the type flags.
* Update the developer.gnome.org URLsEmmanuele Bassi2021-08-051-1/+1
| | | | | | | The GNOME developers documentation website has been updated, and we're in the process of moving API references elsewhere. The old documentation is still available under developer-old.gnome.org, so let's update the URLs we have in our documentation.
* Add glib:name to enum memberMarc-André Lureau2021-06-205-6/+9
| | | | | | | 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-1/+5
| | | | | | Don't rely on runtime name, but on C header parsed symbol. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
* giscanner: Improve error handling while parsing macrosDavid King2021-06-181-3/+29
| | | | | | | | | Check for errors during g_file_open_tmp() and fdopen(). Make sure to free tmp_name and error as needed. Found with Coverity. https://bugzilla.redhat.com/show_bug.cgi?id=1938731
* Make test suite work with cross-related optionsJohn Ericson2021-05-232-1/+8
| | | | | | | | | | 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`
* scanner: Add more float typesebassi/issue-384Emmanuele Bassi2021-04-261-0/+2
| | | | | | | | | The scanner is chocking on the `__float80` and `__float128` types that are provided by GCC as extensions to ISO/IEC TS 18661-3:2015: https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html Fixes: #384
View Lorry Controller Status