See merge request !437

No need to use macros when C++ gives us the ability to access to object
memers easily

This allows to generate code statically checked by gcc with proper type
checks

This allows to generate code statically checked by gcc with proper type
checks

This is more maintainable and we can have static checks.

tests: Don't use g_assert and g_assert_not_reached in tests

See merge request !430

April maintenance

See merge request GNOME/gjs!428

GTK4 removed the Gtk.Container interface, and added API on Gtk.Widget
to iterate over children instead. While that API is perfectly fine
to use from javascript, implementing the iterable protocol allows
for a more idiomatic use like

  for (let child of widget)
      doStuff(child);

and also provides a convenient replacement for the removed get_children()
method:

  const children = [...widget];

See merge request GNOME/gjs!431

This is no longer used since the ByteArray refactor.

It's dubious whether Helgrind even works at all with SpiderMonkey, so
these entries are doing nothing at best.

To account for changes in mozjs68, and different call stacks of the same
leak in different versions of software.

Some suppressions are no longer necessary.

We also have to tell valgrind not to trace /usr/bin/stat since we use it
in a script test.

The previous code would produce a blank on 0 errors, not 0.

This glob expression didn't cover logs like testlog-valgrind.txt.

In order to prevent bugs like the previous, make sure that all counters
are exactly 0 at the end of the run, not just not greater than 0.

Oops, this counter was never incremented.

In this loop, if an early element failed to release, then releasing
subsequent elements could call JSAPI functions with an exception already
pending. JS::AutoSaveExceptionState should do what we want here:
temporarily clear the exception, then put it back at the end of the
scope unless another exception was thrown.

It's not necessary to pass in the information about whether the function
is a method or not, it's available from the function's GICallableInfo.

Fix the type of function->info to be GICallableInfo. In some cases it's
not a GIFunctionInfo, as can be found out by trying to call a
GIFunctionInfo method on it unconditionally.

If you have a JSObject for the 'this' object, a JS::Value array for the
arguments, and a mutable JS::Value for the return value, then that's
basically a JS::CallArgs.

The only difference is that when calling a constructor, you may not be
able to get the 'this' object from args.computeThis(). For
gjs_invoke_constructor_from_c(), we need to provide the 'this' object
that was provided to the constructor.

We had two separate ways of invoking a JS constructor function, one was
used in union_new and the other in Fundamental::invoke_constructor. The
original one, gjs_invoke_c_function_uncached(), was added by Colin in
commit 47381c92 and was intended for
constructors that didn't need the fast path of caching their function
data.

The other, gjs_invoke_constructor_from_c(), was added later for
fundamental type support and did cache the function data, but did not do
argument marshalling on the return value, just returning the C pointer
instead.

Both of these features are useful for both situations, so we merge the
two functions into one gjs_invoke_constructor_from_c() which does not
cache the function data and does not do argument marshalling on the
return value.

Since we now invoke the constructor by its GIFunctionInfo, we don't need
to store its name on FundamentalPrototype, which allows us to remove
actually a lot of code for storing and tracing the property key.

In gjs_invoke_c_function it should be the case that either the JS return
value is wanted, or the GIArgument return value, not both. Ensure this
with an assertion, and use only one condition throughout the body of the
function.

Use type inference to clean up the invocations of gjs_invoke_c_function
a bit.

Where possible, use Mozilla's vector methods to append and initialize a
bunch of elements at once, or reserve capacity and then append
infallibly. This avoids reallocating memory for the vectors inside a
loop.

We already keep a flag in the private data to tell whether the importer
is the root importer, so it's not necessary to infer it by checking the
__modulePath__ property.

GTK4 now removed GtkContainer altogether rather than just child
properties.

These objects don't need to be rooted, since these methods cannot cause
a garbage collection.

This method used to be broken in SpiderMonkey, but it's been fixed for a
long time now.

Starting with SpiderMonkey 68, the standards-compliant trimStart() and
trimEnd() replace the old trimLeft() and trimRight().

gjs_log_exception() already checks if an exception is pending, and
returns false if not.

Fix CI

See merge request GNOME/gjs!433

Combining the old Docker image in one stage of the build with the new
Docker image in a subsequent stage, was causing problems because the
artifacts uploaded by the first build were owned by root.

This should fix the recently failing CI jobs.

We don't want the GSettings test in testGio.js trying to contact a real
dconf daemon.

Its headers produce compiler warnings, so we need to mark them as system
includes. This requires Meson 0.52.

Build new test CI images with Buildah

See merge request !429

Unfortunately, we can no longer use Docker because the runners are
unprivileged.

These macros are no-ops if GLib is built with G_DISABLE_ASSERT, so they
are not appropriate to use in tests.

See: #298

Closes: #318

See !427