Commits on Source (20)
-
Philip Chimento authored
ByteArray.fromGBytes() would crash if the GLib.Bytes had zero length. Anticipate this case and just create an empty Uint8Array.
1a71d5b0 -
Philip Chimento authored
Similar to the bug fixed in the previous commit, going through the non-UTF-8 path of ByteArray.fromString() with a zero-length string would crash. Create an empty Uint8Array here as well.
e2872de0 -
GLib upstream has renamed its `master` branch to `main`. See https://gitlab.gnome.org/GNOME/glib/-/issues/2348 . Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
5b8c108d -
Only construct-only properties defined in JS GObject subclasses need to poke into the several property accessors. This is notably superfluous if the construct-only property comes from a parent GObject in C-land (since then the JS object should not define the JS properties for it). Avoid doing this with construct-only properties not defined by JS objects.
b4627874 -
Construct-only properties may be defined several times in JS land with different casings (snake, kebab, camel), but they all resolve to the same GParamSpec. For these cases, discard the redundant GParamSpec lookups when collecting the value array for g_object_new_with_properties(). Fixes: https://gitlab.gnome.org/GNOME/gjs/-/issues/422
9d669e2b -
Fixes #269
8a8367cd -
9788bc54
-
Previously the module could resolve while we were awaiting the source load and cause an import error.
68a390ff -
From my research it seems like .get() triggers an ExposeGCThingToActiveJS call which can't be called while the heap is collecting - we guard against that case in expose_to_js. Fix this by just queuing toggle ups if the heap is collecting. I'm pretty sure we're hitting this case: https://gitlab.gnome.org/GNOME/glib/-/blob/main/gobject/gobject.c#L4635 I tested it and it seems like we're not getting a toggle up on the object that is actually being finalized, so my only thought is perhaps it is an object that the object getting temporarily toggled up holds a reference to? If that is the case, I think it makes sense to guard toggles while the heap is collecting.
9480313a -
Philip Chimento authorede63e01de
-
Philip Chimento authoreddd4944f4
-
g_build_filename does not work on URIs on Windows as it will use \ which are only valid *file* separators, not URI separators. We should stick to the GIO child APIs and avoid using GLib primitive file APIs.
d03ec598 -
Philip Chimento authored
When building with gobject-introspection as a subproject, we want to find the sources for the gobject-introspection tests in the subproject's source tree, not installed. Querying the gobject-introspection dependency for a 'gidatadir' variable doesn't work if it's a subproject, because the subproject doesn't export a variable by that name. Instead, use the variables that it does export to locate the Regress and GIMarshallingTests sources. (It doesn't currently export any variable for WarnLib, so skip that test in the subproject case. I have opened a merge request to add this to gobject-introspection.) This is based on what PyGObject does.
60034b66 -
Philip Chimento authored
If building GLib as a subproject, it won't have a pkgconfig file to tell where its install prefix is. It's most likely being built as a subproject because the host system has an outdated version, not because it has no version. Also, the user is most likely not running Valgrind. Given that, it's probably OK to just fall back to the suppressions file in /usr.
20744ac4 -
g_error_new_literal() only enforces the precondition that the domain must be greater than 0, but will crash later if it doesn't correspond to a valid GQuark. We can check for that in an override and throw an error if it doesn't. (If the GQuark is valid, it may or may not correspond to an error domain. We can't tell, but while a domain of `GLib.quark_from_string('void')` is weird, it doesn't do any harm) https://gitlab.gnome.org/GNOME/gjs/-/issues/433
5b51db65 -
Philip Chimento authored
I know these are not the names of the merge requests, but whatever. Unreviewed, pushing to fix build.
70fdebe3 -
Philip Chimento authored15821d50
-
Philip Chimento authored44999624
-
Simon McVittie authoredd62200bc
-
Simon McVittie authored1c50cf67