`GIIrNodeEnum` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`GIIrNodeField` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
This also includes some offset validity changes which were forgotten
from commit 515b3fc1dc.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`GIIrNodeVFunc` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`class_closure` isn’t actually meaningfully set anywhere in the code yet
(there are FIXME comments), so I’m not sure of the best type for it. But
generally `unsigned` is more widely used than signed `int`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`GIIrNodeType` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`g_strdup(NULL)` is guaranteed to return `NULL`, so there’s no need to
branch to handle that.
Add a stub private doc comment to hold a `(nullable)` annotation for
that argument, though, so that information isn’t lost.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Might as well move to a modern way of declaring GObjects. This means
that `GIRepository` is no longer derivable, but it would be a bit
unexpected if anyone was deriving from it.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This is just for future reference for people reading the code in future.
I was going through and checking to see if any of them needed to be made
`const` (none of them did).
I did find a couple of memory leaks though; see the following commits.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
By shifting responsibility for ensuring that the lifetime of a
`GIRepository` always exceeds the lifetime of any of its `GIBaseInfo`s
to the user.
Keeping a weak ref from each `GIBaseInfo` to its `GIRepository` would be
too expensive (`GIBaseInfo`s are supposed to be cheap to create and
destroy, as they are used within function calls in language bindings).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3234
Don’t allow the `pages` job to be run (even manually) on post-merge
pipelines. It’s not particularly useful, and GitLab doesn’t like having
a manual job with unsatisfied dependencies in a pipeline:
```
'pages' job needs 'coverage' job, but 'coverage' is not in any previous stage
'pages' job needs 'style-check-advisory' job, but 'style-check-advisory' is not in any previous stage
```
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3847#note_1986044
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
g_strndup() internally uses strncpy(), while g_strdup() uses memcpy().
Most likely, memcpy() is faster.
Instead of strlen()+g_strndup(), use g_strdup() as we don't need the
length.
In some merge requests there are bits (such as memory leaks) that we may want
to test before merging and that the schedules will run them.
As per this add a rule to make them manual, and apply it to some jobs.
This fixes many things from the port to gi-docgen, but also improves
documentation more generally.
Main improvements/fixes:
- Fix links to functions, constants, etc.
- Rewrite code syntax to work with Markdown
- Reduce indentation (do not indent by 4 to prevent code blocks)
- Remove redundant text such as "can be NULL" or "should be freed"
- Move text from large return info texts to main function text
- Remove periods at the end of parameter and return descriptions
- Do not capitalize the first word of a parameter or return description
- Try to improve consistency between docs for similar functions
- Convert %TRUE and %FALSE into true and false
- Convert other uses of `%` and `#` into inline code
Helps: #3037
Fixes broken links, and removes `%` and `#` notation in favor of inline
code, and limits indentation to two to prevent accidental formatting.
Fixes some style issues too, mainly removing periods at the end of
parameter and return descriptions.
Also removes trailing whitespace from the doc comments.
Helps: #3037
These flags were replaced by gi_callable_info_can_throw_error() in
girepository 1.x, but the flags were maintained for backwards
compatibility. No need to hold on to them in the 2.x API.
Note that these flags are also still maintained as separate bits in the
binary format, which is not changing. So, they still need to be read
from FunctionBlob and VFuncBlob if the bit is not set in SignatureBlob.
This is an API break for girepository 2.x, which is OK because the API
has never been released yet.
These tests come from gobject-introspection/tests/repository/. They
include whatever wasn't already covered by the existing tests.
The original files didn't have copyright information. That's been
reconstructed from commit messages of commits that added a test or a
substantial part of one.
This brings its naming more in line with modern GLib conventions.
This is an API break, but libgirepository is not API frozen yet.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This test case was originally written by Philip Chimento as a reproducer
for #3218. Let’s add it to the test suite to catch regressions in
stack-allocated `GIBaseInfo` handling.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3218
Most of the code for handling stack-allocated infos was correct, it was
just missing code to initialise the `GTypeInstance` member.
Since `GTypeInstance` isn’t really designed for stack allocation, this
is a little hacky — it requires setting up the member within
`GTypeInstance` manually. It works, though.
The externally visible consequence of this, though, is that
stack-allocated `GIBaseInfo`s now need to be cleared when they’re
finished being used. This allows the `GTypeClass` ref to be dropped.
All users of the stack-allocated APIs in libgirepository will need to
adapt to this change.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3218
This is one more step towards removing `GIInfoType`, and will also help
in a following commit which will directly make use of the `GType`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3218
As documented in the commit, the internal members of `GIBaseInfo` are
not reffed if the `GIBaseInfo` is stack-allocated, as the caller can be
relied on to ensure their lifetime exceeds that of the `GIBaseInfo`.
Make sure that’s actually reflected in the code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3218
Make it take a `GITypeInfo` rather than a `GIBaseInfo`, because that’s
what it actually operates on.
This is an internal API, so this isn’t an API break.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3218
This fixes a race condition which frequently caused the
`memory-monitor-dbus.py` test to fail.
The registration of the `LowMemoryMonitor` object on the bus, and the
`GMemoryMonitorDBus`’s connection to the warning signal raced, such that
it was possible for the mock `LowMemoryMonitor` to emit a warning signal
before the `GMemoryMonitorDBus` proxy was listening, and hence the proxy
would never see the signal.
Fix this by explicitly synchronising the two before proceeding to the
tests.
Make the same changes in the `memory-monitor-portal.py` test too, even
though that one was not failing. This should remove the need for a 2s
wait on every test run.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #2887
