GitLab

Workaround for https://bugzilla.gnome.org/show_bug.cgi?id=793175
This ignores the warning for G++ 8 and later (which is apparently when it
was added.)

Closes #117.

Simon McVittie authored Jan 30, 2018 and Philip Chimento committed Jan 31, 2018

We probably don't actually want to abort or trap here, because there's
a GError passed back to the caller, which is (hopefully) going to
handle the exception gracefully; but an uncatchable exception indicates
that something has gone badly wrong, so we should make some noise, and
log a critical that can easily be made fatal by developers.
Signed-off-by: Simon McVittie <smcv@debian.org>

Simon McVittie authored Jan 30, 2018 and Philip Chimento committed Jan 31, 2018

Callers should have the opportunity to distinguish between an
ordinary exception and an uncatchable exception. gjs_log_exception()
isn't necessarily going to give us anything useful for an
uncatchable exception.
Signed-off-by: Simon McVittie <smcv@debian.org>

Simon McVittie authored Jan 30, 2018 and Philip Chimento committed Jan 31, 2018

If the call into JavaScript returns false without setting the
exception, then either we're trying to exit, or something has gone
badly wrong.
Signed-off-by: Simon McVittie <smcv@debian.org>

We actually don't want callers to have control over the lifetime of the
profiler object. It should be tied entirely to the GjsContext. This makes
most of the profiler API private.

Now, to control the profiler, you have two construct-only properties of
GjsContext: profiler-enabled and profiler-sigusr2. profiler-sigusr2
implies profiler-enabled, and does the work that
gjs_profiler_setup_signals() would previously have accomplished. The
GJS_PROFILER_ENABLED environment variable, if set, overrides the value of
profiler-signal.

By default when you call gjs_context_eval(), the profiler will be started
and stopped automatically around the evaluation of the JS code. If you
need to call gjs_context_eval() more than once, you probably only want to
do that within one profiling session. For that case we provide the
gjs_profiler_start() and gjs_profiler_stop() API, which will prevent the
auto-starting and stopping.

This checks in gjs_context_eval() to see if the GJS_ENABLE_PROFILER
environment variable is set but no profiler has been created. In that
case, we run a profiler for the duration of the JS code evaluation.

This is to accommodate applications such as Polari that are written in JS
but ship their own loader that links to libgjs and calls
gjs_context_eval(). This way, they can be profiled without writing any
extra code in their loaders (though they will still need it if, for
example, they want to add a command line argument.)

Ever since removing the gjs-module API, there has not really been a
distinction between "public" and "private" jsapi-util functions. Just
remove the private files and incorporate everything declared or defined
there into the other jsapi-util files.

Based on a patch by Jasper St. Pierre. This allows executing a JS script
(which must be a resource in the directory
resource:///org/gnome/gjs/modules/_bootstrap) in order to define extra
properties on a global object when the global object is created.

This is currently not used for anything, but will be used for the code
coverage compartment, and likely for a debugger as well. It can also be
used to implement things in JS that are currently implemented in C++,
like the log() and logError() functions.

https://bugzilla.gnome.org/show_bug.cgi?id=777724

gjs_context_eval_file() was returning false but not setting the error
parameter if the file did not exist.

That check makes no sense anyway, since it is also done by
g_file_load_contents(). Therefore we remove it and take the opportunity
to refactor the function to use autoptrs.

https://bugzilla.gnome.org/show_bug.cgi?id=786995

gjs_object_prepare_shutdown() doesn't need to access the JSContext.

https://bugzilla.gnome.org/show_bug.cgi?id=786668

Philip Chimento authored Aug 11, 2017 and Philip Chimento committed Aug 13, 2017

Newer JS defines a columnNumber property on Error objects, so our
GError-backed ones should have this property as well.

https://bugzilla.gnome.org/show_bug.cgi?id=786183

Philip Chimento authored Jul 18, 2017 and Philip Chimento committed Jul 19, 2017

The std::array object in GjsContext never had its constructor and
destructor called. That happens to work, but it depends on the
implementation, so do it properly.

https://bugzilla.gnome.org/show_bug.cgi?id=784713

A known gotcha with promises is forgetting to attach a .catch() handler,
in which case a failed promise is swallowed silently. This will log a
warning when that happens.

https://bugzilla.gnome.org/show_bug.cgi?id=784713

SpiderMonkey 52 includes native promises, so we can remove the embedded
JS implementation of promises. Queueing up and resolving of promises is
now done inside SpiderMonkey itself, and we must implement some
SpiderMonkey extension points in order to get this to integrate with our
GLib main loops.

The implementation is adapted from what SpiderMonkey does internally in
its js::RunJobs() function; see the code in jscntxt.cpp.

https://bugzilla.gnome.org/show_bug.cgi?id=784713

JSRuntime is merged into JSContext in SpiderMonkey 52.

We reorganize things a bit to reflect the new situation. The files
runtime.cpp and runtime.h are renamed to engine.cpp and engine.h, and
will contain everything having to do with the SpiderMonkey engine:
initializing the JSContext, and any callbacks that the engine requires
embedders to set.

https://bugzilla.gnome.org/show_bug.cgi?id=784196

Many APIs that adapted to the removal of JSRuntime can be trivially
replaced with JSContext without any other code changes.

JS_AbortIfWrongThread() also takes JSContext instead of JSRuntime, but
we only called it to check that we were creating a JSContext on the
correct thread. Before creating the JSContext, there is no point in
calling it, so remove it.

https://bugzilla.gnome.org/show_bug.cgi?id=784196

JS::RuntimeOptions and JS::ContextOptions have merged into one
JS::ContextOptions class. JS::CompartmentOptions, on the other hand, has
split into "creation options" (can be set only at construct time) and
"behaviors" (can be changed at run time.)

The DontReportUncaught option is removed and is now activated
unconditionally.

https://bugzilla.gnome.org/show_bug.cgi?id=784196

Replacing the old JS_CallFooTracer() API is a new C++ JS::TraceEdge<T>()
function. It works the same, but is templated. The old API will be going
away in SpiderMonkey 52.

https://bugzilla.gnome.org/show_bug.cgi?id=784196

JS::NullPtr() is gone, and instead now functions that took JS::NullPtr()
as a null handle value take nullptr_t, so we should use C++ nullptr.

https://bugzilla.gnome.org/show_bug.cgi?id=784196

In order to more easily create global objects, we refactor code that
deals with them into gjs/global.cpp and gjs/global.h. Previously global
objects were set up partly in gjs_context_constructed() and partly in
gjs_init_context_standard(); we disentangle that code and move everything
dealing with setting up the GjsContext into gjs_context_constructed(),
while global object setup moves to gjs_create_global_object().

Since global objects all share the same root importer, we must split the
setup into two. Creating the root importer is the responsibility of
gjs_context_constructed(), and it requires that the first global has been
created. After creating the root importer, the global object is finished
with gjs_define_global_properties().

In the case of global objects beyond the first, such as the global object
for the coverage compartment, gjs_define_global_properties() will also
wrap the root importer in a cross-compartment wrapper so that the new
global can access it.

https://bugzilla.gnome.org/show_bug.cgi?id=781429

This completes the transition of the code to std::unique_ptr so that we
can be assured that we use JS_free() on items that are acquired via
pass-by-reference via SpiderMonkey APIs, and thus we can remove more of
the g_free() calls on those as SpiderMonkey may switch to a different
allocation/deallocation implementation internally (which is currently
free()).

https://bugzilla.gnome.org/show_bug.cgi?id=777597

The thread facilities are going away in SpiderMonkey 52, so we use GThread
to determine a context's owner thread in order to be able to check it
later. (g_thread_self() will still work if GLib didn't create the thread.)

https://bugzilla.gnome.org/show_bug.cgi?id=781429

JS_SaveExceptionState() seems to be broken in SpiderMonkey 45, but in any
case we can work around it by using the more modern RAII version. Since we
are using JS::RootedString here we can also get rid of the trick of
stuffing the string into one of the JS::CallArgs' slots to root it.

https://bugzilla.gnome.org/show_bug.cgi?id=781429

I finally figured out why my highlighting was always messed up; the mode
lines in all these files said "C" whereas they were C++ or JS files. This
was in such a blind spot that I even copied it to new files that I had
created in the meantime...

Unreviewed.

Philip Chimento authored Mar 09, 2017 and Philip Chimento committed Apr 01, 2017

In order to minimize the chances of a JS object being garbage collected
while it is queued to toggle up, we handle all pending object toggles
when garbage collection starts.

https://bugzilla.gnome.org/show_bug.cgi?id=778862

Philip Chimento authored Mar 07, 2017 and Philip Chimento committed Mar 07, 2017

If an "uncatchable" (SpiderMonkey term) exception is thrown (that is,
return false from a JSAPI call without an exception pending on the
JSContext), then we have to deal with the condition when returning back
to C code. We use the uncatchable exception mechanism to implement
System.exit(), and so gjs_context_eval() checks for this and exits if
appropriate.

However, when calling System.exit() inside a callback marshalled by FFI,
the uncatchable exception propagates up to gjs_callback_closure() and
stopes there. There is nothing that can propagate the exception after
that point. There may be one or more main loops running, and until they
exit, we don't even get back to our JSAPI code that will propagate the
exception up to gjs_context_eval().

Therefore, we do a "dirty exit" (our term) if an FFI callback throws an
uncatchable exception. This will, unfortunately, trip an assertion if
SpiderMonkey is compiled in debug mode, because we haven't cleaned up the
JSContext by the time the JSRuntime is destroyed when the thread exits.
We can't clean up the JSContext, either, because the caller of
gjs_context_eval() is still holding a request on the JSContext so if we
did that we would trip a different assertion.

This SpiderMonkey limitation is reflected in the added test, whereby the
test will still pass if the script exits with any nonzero code, which
covers the debug-mode case where we fail the assertion.

https://bugzilla.gnome.org/show_bug.cgi?id=779692

Each JSRuntime has an associated thread, an "owner thread" in
SpiderMonkey terminology. Most entry points into the JS engine will check
if the calling thread is the owner thread. Since we need to check if we
are on the owner thread in order to decide whether to handle toggle refs
on objects immediately or to defer them to an idle function, we record
the owner thread when constructing the GjsContext and provide an internal
method to retrieve it.

This makes it unnecessary to maintain a static pointer to the owner
thread in object.cpp, which was causing problems because it would not get
initialized if no custom classes were created.

https://bugzilla.gnome.org/show_bug.cgi?id=779693

Some memory leaks uncovered by Valgrind.

https://bugzilla.gnome.org/show_bug.cgi?id=779293

The various flavours of JS_CallHeapFooTracer() are now called
JS_CallFooTracer() in SpiderMonkey 38.

https://bugzilla.gnome.org/show_bug.cgi?id=777962

In object.cpp, we previously kept a GObject's JS wrapper object alive by
adding it to the keep-alive object. We can now use GjsMaybeOwned for this
purpose if we add an accessor function to check whether the GjsMaybeOwned
is in rooted mode.

This is in preparation for an even deeper refactor where we replace the
JS::Heap wrapper stored in the object's qdata with GjsMaybeOwned as well.

This requires a small change to GjsContext's dispose handler so that we
handle all pending toggle notifications before doing the first garbage
collection.

https://bugzilla.gnome.org/show_bug.cgi?id=776966

The previous situation was that a JS::Heap wrapper was used to root a GC
thing under some conditions using JS::AddFooRoot() or the keep-alive
object, and trace or maintain a weak pointer otherwise.

This will not be possible anymore in SpiderMonkey 38. JS::AddFooRoot()
and JS::RemoveFooRoot() are going away, in favour of
JS::PersistentRootedFoo. The keep-alive object has its own problems,
because the SpiderMonkey 38 garbage collector will move GC things around,
so anything referring to a GC thing on the keep-alive object will have to
know when to update its JS::Heap wrapper when the GC thing moves.

This previous situation existed in two places.

  (1) The JS::Value holding a trampoline's function. If the function was
  owned by the trampoline (the normal case), then it was rooted. If the
  function was a vfunc, in which case it was owned by the GObject class
  prototype and the trampoline was essentially leaked, then it remained a
  weak pointer.

  (2) The JSObject associated with a closure. In the normal case the
  object and the closure had the same lifetime and the object was rooted.
  Similar to above, if the closure was a signal it was owned by the
  GObject class, and traced.

For both of these places we now use GjsMaybeOwned, a wrapper that sticks
its GC thing in either a JS::PersistentRootedFoo, if the thing is
intended to be rooted, or a JS::Heap<Foo>, if it is not. If rooted, the
GjsMaybeOwned holds a weak reference to the GjsContext, and therefore
can send out a notification when the context's dispose function is run,
similar to existing functionality of the keep-alive object.

This will still need to change further after the switch to SpiderMonkey
38, since weak pointers must be updated when they are moved by the GC.
(This is technically already the case in SpiderMonkey 31, but the API
makes it difficult to do correctly, and in practice it isn't necessary.)

https://bugzilla.gnome.org/show_bug.cgi?id=776966

Philip Chimento authored Jan 27, 2017 and Philip Chimento committed Jan 27, 2017

This function was identical to gjs_define_repo(), so we can remove it.

https://bugzilla.gnome.org/show_bug.cgi?id=777205

This function added extra roots where they weren't needed; we can clean
it up by taking a JS::HandleObject.

https://bugzilla.gnome.org/show_bug.cgi?id=777205

We put the collection of interned strings into an array of
JS::PersistentRootedId to make sure they are not garbage-collected;
otherwise there was nothing keeping them from being freed.

https://bugzilla.gnome.org/show_bug.cgi?id=776966

This code was due for some refactoring, and changing GjsConstString to be
rooted in the following commit was the opportunity for it. We now have
gjs_object_get_property(), gjs_object_has_property(),
gjs_object_set_property(), and gjs_object_define_property() as wrappers
for JS_GetPropertyById(), etc., that take a GjsConstString constant
instead of a jsid.

In addition, we rename gjs_object_require_property_value() to be an
overload of gjs_object_require_property(); the old name was confusing
because the name _without_ "value" was the one that dealt with a
JS::Value!

Same rename for gjs_object_require_converted_property_value().

This whole thing allows us to get rid of some code, moving a bunch of
roots into these new functions. These roots are strictly speaking still
necessary, but in the next commit we're going to root all the interned
strings permanently, which should have been done all along.

https://bugzilla.gnome.org/show_bug.cgi?id=776966

This did not break before, but in SpiderMonkey 38 not doing this is more
likely to cause crashes because the pointer stored in the JS::Heap
wrapper is more likely to become invalid once it is no longer traced.
This would crash under SpiderMonkey 38 when executing JS::Heap's
destructor, so we should instead empty out the wrapper after removing the
tracer.

https://bugzilla.gnome.org/show_bug.cgi?id=776966

Fundamental was the only class that didn't have the IMPLEMENTS_BARRIERS
flag set. In SpiderMonkey 38 it's required on all classes that have a
trace hook.

In addition, in order to implement barriers correctly we need to make sure
that JS::Heap's constructor and destructor are called. In most cases we do
this by making the containing struct a C++ struct, and calling its
constructor and destructor. In the case of GjsContext (a GObject struct)
and GjsCoveragePrivate (a GObject private struct) we can't do that, so
instead we use placement new on the JS::Heap member.

https://bugzilla.gnome.org/show_bug.cgi?id=776966

Chun-wei Fan authored Jan 18, 2017 and Philip Chimento committed Jan 24, 2017

Use the DllMain() to call JS_Init()/JS_ShutDown() so that we can reduce
the use of constructors on Windows, and ensure that JS_Init() is called
when libgjs is being loaded.  As we automatically get a HINSTANCE/HMODULE
with the DllMain(), make use of it so that we can construct paths to load
introspection items and scripts at runtime so that we do not need to
hardcode paths at build time.

https://bugzilla.gnome.org/show_bug.cgi?id=775868

These lines as they previously were cause compile errors in SpiderMonkey
38. JS::Heap's operators are defined slightly differently than they
previously were.

https://bugzilla.gnome.org/show_bug.cgi?id=776966

Jasper St. Pierre authored Dec 03, 2010 and Philip Chimento committed Jan 05, 2017

SpiderMonkey doesn't have a useful default toString(): [object Object].
When debugging, it's useful to have information like the imported path of
a module, which we previously didn't display.

Original patch by Jasper St. Pierre; rewritten for current GJS by Philip
Chimento.

https://bugzilla.gnome.org/show_bug.cgi?id=636283