| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
| |
This changes the gjs_whatever_create_proto() functions generated by the
GJS_DEFINE_PROTO macros in jsapi-util.h to be correctly rooted, letting
changes to those function prototypes cascade everywhere else.
https://bugzilla.gnome.org/show_bug.cgi?id=742249
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We got rid of all the "compat" stuff in compat.h already, before this
commit it only included jsapi.h, jsdbgapi.h, and jsapi-util.h, wrapping
the former two in some diagnostic pragmas. If we get rid of the
jsapi-util.h include, then we can use a system_header pragma to mark it
as a system header so that we don't have to painstakingly maintain all
those diagnostic pragmas.
(The system_header pragma ignores all warnings coming from that file:
https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html)
Since compat.h already wasn't a fitting name anymore, rename the header
to jsapi-wrapper.h.
https://bugzilla.gnome.org/show_bug.cgi?id=773297
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting with gjs_object_get_property_const() and working backwards, we
cause another cascade of GC rooting changes.
One disadvantage of JS::MutableHandle is that it's not so easy to make an
optional out parameter for a function. Previously, for example, a
JSObject** parameter could be NULL to indicate the caller wasn't
interested in the return value. e.g.,
if (out_obj != NULL) { do_some_op(); *out_obj = something; }
Now we have a few options. For those optional parameters that eventually
get passed as the "constructor" out parameter of gjs_init_class_dynamic(),
the constructor is going to need to be created anyhow. So there it's best
to pass an ignored handle in.
In gjs_context_get_frame_info(), where we can avoid doing some work by
indicating that we don't need the particular out parameters, we use
mozilla::Maybe. This has an unwieldy API in mozjs24 but is improved to be
much more convenient in later releases. (If this were C++17, we could use
std::optional instead.)
https://bugzilla.gnome.org/show_bug.cgi?id=742249
|
| |
|
|
|
|
|
| |
Now this API is not public anymore, the deprecated functions can be
removed entirely.
https://bugzilla.gnome.org/show_bug.cgi?id=772386
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In mozjs31, JSBool and its values JS_TRUE and JS_FALSE are discontinued
in favor of regular C++ bool, true, and false. In order to ease porting
to mozjs31, we switch to C++ booleans everywhere.
Almost everywhere, that is. In some cases bool *, or function pointers
with bool return types, will not automatically be cast. We therefore leave
a few instances of JSBool in the code. These will be removed when the
actual port to mozjs31 happens.
Fixes a few formatting glitches in lines of code that were touched
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=742249
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
According to the comments, in mozjs 1.8.5, JS_NewObjectForConstructor()
did not work with our dynamic classes. Therefore a
gjs_new_object_for_constructor() shim was created that copied the
JS_NewObjectForConstructor() code from mozjs 1.9. Now that we are on
mozjs 24, we can get rid of this shim.
Unfortunately we can't remove the function altogether because it's public
API in libgjs.
https://bugzilla.gnome.org/show_bug.cgi?id=742249
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Macros such as JSVAL_IS_STRING, JSVAL_TO_BOOLEAN, OBJECT_TO_JSVAL, etc.,
are removed in mozjs31. Instead, use the equivalent methods of JS::Value.
This would be fairly straightforward except for JSVAL_IS_OBJECT,
JSVAL_TO_OBJECT, and OBJECT_TO_JSVAL. Contrary to what the names imply,
these macros deal with values that are either objects or null. The newer
API's isObject(), toObject(), and JS::ObjectValue() do not include null.
Strictly speaking, all uses of JSVAL_TO_OBJECT should be replaced by the
isObjectOrNull() method, and likewise for the other OBJECT macros.
(JSVAL_IS_OBJECT had already been removed from the API in an earlier
SpiderMonkey release and was implemented as a shim in compat.h; this shim
is now removed.)
However, there were many cases where
- it was already ruled out that a value was null;
- it was already ruled out that a JSObject pointer was null;
- or, in my opinion the existing code erroneously allowed a null value.
In these cases, I have replaced the OBJECT macros with the equivalent
Object methods.
A few strange undocumented macros were also used; JSVAL_IS_TRACEABLE
seems to be equivalent to JS::Value::isGCThing().
https://bugzilla.gnome.org/show_bug.cgi?id=742249
|
| |
|
|
|
|
|
|
|
|
| |
JS::Value is the new-style API. Nowadays jsval is simply a typedef for
JS::Value for convenience, but since we will be updating everything to
the JS::RootedValue, JS::HandleValue style API in mozjs31, we may as well
go through and weed out all usage of jsval in favor of JS::Value for
clarity.
https://bugzilla.gnome.org/show_bug.cgi?id=742249
|
| | |
|
| |
|
|
|
| |
It needs to be here, as const strings are context-dependent, and one
JSRuntime needs to host multiple contexts.
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=710878
|
