| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
The __ia64 and __x86_64__ macros are defined for GCC but not Visual
Studio, but actually this code path should also be taken for Visual
Studio when doing a 64-bit build (x86_64/x64 and aarch64/arm64, _WIN64
will be defined for these cases), since Windows is an LLP64 platform.
This will avoid C4311/C4312 warnings on Visual Studio builds, which are
often warnings of concern as we are dealing with pointers with differing
sizes on 32-bit and 64-bit Windows builds.
|
|
|
|
|
|
|
|
|
| |
Later GLib versions assume that warning C4715 is an error as we want ot
be sure that functions that return a value do indeed return one by all
means.
Avoid this warning by adding a 'return 0' in brz_search_packed(), it
might be pointless but does indeed avoid the warning.
|
|
|
|
|
| |
It's pointless, as docbook's style sheets do not work any
more, but gtk-doc still warns about them.
|
|
|
|
| |
It must match the argument in the definition and the documentation.
|
| |
|
|
|
|
| |
Now that we have it.
|
|
|
|
|
| |
And deprecate G_TYPE_TAG_IS_BASIC. Let's avoid hijacking
the G namespace any further.
|
| |
|
| |
|
|
|
|
|
| |
We are still using gtk-doc, but gtk-doc uses Markdown these days, not
DocBook.
|
|
|
|
| |
It's `/*< ... >*/`, not `/* <...> */`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new API does the same thing as gi_type_info_extract_ffi_return_value,
but takes a GITypeTag instead of GITypeInfo pointer, and additionally a
GIInfoType if the GITypeTag is GI_TYPE_TAG_INTERFACE. (These pieces of
data are the only things used from the GITypeInfo structure.)
It's intended for bindings using an argument cache, such as GJS and
PyGObject, so that they don't have to store a whole 64-bit GITypeInfo
pointer in their cache in many common cases, and can just store the 5-bit
type tag instead, or the 5-bit interface type in case of
GI_TYPE_TAG_INTERFACE.
The original gi_type_info_extract_ffi_return_value() is reimplemented in
terms of the new gi_type_tag_extract_ffi_return_value().
|
|
|
|
|
| |
It was driving me crazy that g_type_info_get_array_length() claimed to
return an array length.
|
|
|
|
|
|
|
| |
The documentation comment for SimpleTypeBlob seemed to imply that a basic
type was embedded if the reserved fields were nonzero. After examining the
code, I believe that was actually due to some words missing, and the
comment should say that the type is embedded if the fields are zero.
|
|
|
|
|
| |
Like GI_TYPE_TAG_IS_NUMERIC, this is a convenience for bindings that want
to perform a similar action for all container types.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a convenience for bindings that want to perform a similar action
for all numeric types. It allows more expressive code in some cases:
if (GI_TYPE_TAG_IS_NUMERIC(tag)) {
do_one_thing();
return;
}
switch (tag) {
case GI_TYPE_TAG_ARRAY:
do_other_thing();
return;
/* ... */
default:
g_assert_not_reached();
}
instead of listing out all of the numeric types in the switch statement.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This is based on f9c08308ea0c25977b4e0153e868cb0a8703b75e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
We need to use log_node(), not a plain log().
|
|
|
|
|
| |
We prefer methods, signals, and virtual methods to properties, in case
of a collision.
|
|
|
|
|
| |
This way we only raise a warning when operating under the newly added
strict mode.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
| |
This is based on c7031164b13d1e184aeaf5850a10897b06269735
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Fixes #416
|
|
|
|
| |
This is based on 0ea10bf904e2098739fe0f5df52be549343effa9
|
|
|
|
| |
This is based on d41282f7a85b0e1be61505ae85125a977a8ac557
|
| |
|
| |
|
|
|
|
|
|
|
| |
If a <GType invalid> (that's the way it appears in python's debugger) is
returned, `g_type_name` returns NULL. This
function therefore returns NULL at this time
as subsequent calls to `strlen( data->gtype_name)` segfault.
|
|
|
|
|
| |
We can use them in Gjs to verify whether a value is properly packed
and unpacked to GValue.
|
|
|
|
| |
It's the only basic type missing, better to have for consistency.
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This can be used to test we don't do unexpected conversions between
invalid types.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
Newer versions of the GNU libc have started to warn if the result of the
call is unused.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
We are going to use additional API that is only available since 0.57,
but since 0.57 is a very old version, let's skip it.
|