Not sure if we should go this route or wrap in a callback, I'd prefer if we can go this route to avoid adding JS wrapping
We're currently keeping a list of trampolines in a static vector, this is acceptable (at least for a single-context scenario), but trampolines are bound to a specific context so better to move the handling in the context.
GjsMaybeOwned had a notification support that was used only by Closures (other than tests), this was causing adding an extra pointer to all the types using it (including Object) that was mostly unused. So, move this into private context, re-implementing it using our own notifier (instead of relying on GObject's that needs a specific order) and use it in closures. Also add an hook to handle gc events on private context that will be in later changes to cleanup more things, but for now is used to shrink the closures vector once we've done.
The callback trampoline is in fact a GClosure, but we were just composing one. We can instead just inherit from it now, given that the Gjs::Closure will allocate the needed memory via the closure allocator and handle the references via native closure reference system (avoid to duplicate that). As per this, some less memory used as we save a pointer and the reference counting. The only bit we need to handle is the destruction as we need to be sure to call the proper type destructor on closure finalization. So, adding an utility function that ensures this happens for each type and that we won't call the base destructor twice.
To create closures we used to create an internal closure structure that for which we were handling construction and destruction manually. C++ allows us to use some nicer features though, and we can take advantage of them once we leave the role of allocating and deallocating the memory to GClosure functions. This can be nicely done overriding the new and delete operators that will give us the size to allocate exactly as the closure creator function expects to receive.
There's a such definition in readline and this breaks building both with pch and with unity builds
arg-cache: Never throw when building the argument cache Closes #386 See merge request GNOME/gjs!590
As per commit d37d6604 and commit c0003eb we may destroy an object wrapper earlier than we used to do, this has some memory benefits but we also need to make sure that we cleanup the object qdata so that it never points to the just free'd object wrapper. By doing this, however, we may end up re-associating a GObject that is disposed but not yet finalized to another valid wrapper. This was allowed before but wasn't really correct either because in such case it will be just useless and won't be able to monitor its disposal again. So, now during disposal notify save a qdata (that won't be removed until finalization) on gobject marking it as disposed, then use this data to prevent an object to be re-associated again to a valid wrapper. In fact we just create a new wrapper that is marked as "disposed", and so preventing most of actions to be performed. We don't warn though, because this may just happen at the moment the invalid object is incorrectly used. As per this, we need to unset the object qdata only if the object is not finalized, as we may still need to do it when it's finalized, or we'll still crash when a disposed GObject will point to a wrapper that has been already destroyed. Added tests simulating this. Fixes: #395
In JS you can throw not only Error objects, but any value. If throwing a value from a signal handler or vfunc with a GError** parameter, then that value should be converted to a GError whether it is an Error object or not. Rename gjs_gerror_make_from_error() to gjs_gerror_make_from_thrown_value() and refactor it to get the pending exception (thrown value) from the context, and convert that into a GError. If the object does not have a 'name' and 'message' property then it's converted into a GJS_JS_ERROR_ERROR with an appropriate debug message; if it does, then it's converted into the appropriate type of GJS_JS_ERROR.