| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
We are redefining the gc policy in multiple places while we can just it
once in the jsapi util header and include it when it's not the case
|
| |
|
|
|
|
|
| |
This will help us avoid failing the static_assert in js/GCPolicyApi.h where
pointer types are not allowed, when building with Visual Studio, which is
caused by the compiler not picking up the needed types when js/GCPolicyAPI.h
is included in some way or the other.
|
| |
|
|
|
|
| |
Remove the usage of the GJS_DEFINE_PRIV_FROM_JS and GJS_DEFINE_PROTO
families of macros from the Cairo pattern wrapper types. Use CWrapper
instead, for more type safety and less boilerplate.
|
| |
|
|
|
|
|
|
| |
The SPDX format is machine-readable, which should make it much easier to
avoid mistakes with licensing and copyright using automated tools.
This commit does not add any implicit information. It converts exactly
what was already specified into SPDX format comments.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we depend on C++17, we can use these attributes that are part
of the language, instead of relying on macros to make them portable.
(GJS_USE still needs to be defined for public header files, which may be
compiled in C.)
Attributes which are new in C++17 are [[maybe_unused]], [[nodiscard]],
and [[fallthrough]].
[skip cpplint] because cpplint doesn't deal with C++ attributes:
https://github.com/google/styleguide/issues/165
|
| |
|
|
|
|
|
|
| |
SpiderMonkey 78 will stop using the JSClass.name string as the string
tag. For backwards compatibility, we should make sure the string tag
doesn't change.
See: GNOME/gjs#329
|
| |
|
|
|
|
| |
Instead of allocating a separate private struct that allocates a
cairo_pattern_t, use the cairo_pattern_t directly as the private struct.
This makes the code simpler and saves 8 bytes per object.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
With SpiderMonkey 68, it's no longer necessary to mark SpiderMonkey
header files as system headers, and it's also no longer necessary to
include <js-config.h> before any other header files, as SpiderMonkey
has sorted that out internally.
We remove jsapi-wrapper.h and define DEBUG directly in config.h instead
of indirectly in jsapi-wrapper.h via HAVE_SPIDERMONKEY_DEBUG.
This should reduce compile time, on average, because in most .h files
we now only need to include <js/TypeDecls.h>.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously #include statements were a bit of a mess across the codebase.
This commit is the result of a pass by the IWYU (Include What You Use)
tool, which suggests headers to add or remove based on what is in the
file, and can also suggest forward-declaring classes instead of
including their headers, if they are only used as a pointer in a
particular file. Cleaning this up should in general speed up compile
times.
IWYU isn't perfect, it produces a number of false positives, so we don't
try to automate this process and we don't accept all of its
recommendations. We do add a script and configuration file to the tools/
directory so that IWYU can be every so often in the future.
We also clean up all the includes according to a consistent style, which
is now described clearly in the C++ style guide.
|
| |
|
|
|
|
| |
In files where the IWYU tool would recommend including <stddef.h> only
for the symbol NULL, we instead remove usage of NULL in favour of
C++-style nullptr, or implicit conversion to bool.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces two annotations to functions. GJS_USE is a macro for GCC
and Clang's "warn_unused_result" annotation, meaning that the return
value of a function must not be ignored. This allows us to catch some
cases where we are neglecting to do error checking.
The second annotation is GJS_JSAPI_RETURN_CONVENTION which for now is
identical to GJS_USE, but could be made into a custom annotation in the
future which a static analyzer plugin could use to enforce further checks
at compile time. The "JSAPI return convention" is valid on functions that
return bool or a pointer type, and whose first parameter is JSContext*. If
false or nullptr is returned, then an exception must be pending at return
time on the passed-in JSContext. If true or a non-nullptr value is
returned, then no exception must be pending.
This commit only has the addition of the attributes, and a few fixes
mandated by the autoformatter, so it can be reviewed "lightly".
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This allows the GJS_DEFINE_PROTO_* family of macros to have a JSFunctionSpec
array for functions defined on the constructor, rather than on the
prototype: i.e. static functions.
We clean up an incongruity in cairo-image-surface.cpp where you had to pass
the constructor into gjs_cairo_image_surface_init() in order to get the
static functions defined.
https://bugzilla.gnome.org/show_bug.cgi?id=614413
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This refactors the GJS_DEFINE_PROTO family of macros to store the created
prototype objects in slots on the global object. We split up the
gjs_WHATEVER_create_proto() function into two functions: one that must be
called at least once for each type to define the class, store the prototype
in a global slot, and define the constructor as a property on a passed-in
module or global object, gjs_WHATEVER_define_proto(); and one that
retrieves the prototype from its global slot, gjs_WHATEVER_get_proto().
We also add two macros, GJS_DEFINE_PROTO_WITH_PARENT and
GJS_DEFINE_PROTO_ABSTRACT_WITH_PARENT, which also move the definition of
the parent to compile time rather than runtime, and keep it in the same
place as the rest of each class's macro definition. Similarly, previously
we had to pass the parent prototype object to gjs_WHATEVER_create_proto().
This mostly affects the cairo module.
https://bugzilla.gnome.org/show_bug.cgi?id=614413
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's no need to have a "proto_name" that's different from the class's
name. Getting rid of this distinction will allow us to refactor things so
that JS_InitClass() defines the correct constructor directly on the global
object or the module object.
This is a small behavioural API break, since it changes the output of
toString() on the various Cairo objects, but I would say that people
should not be parsing the output of toString(). (I know we do in our tests,
but that's terrible.)
https://bugzilla.gnome.org/show_bug.cgi?id=614413
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
I've been wishing I had done this for three days now; jsapi-util.h is far
too long, and it's no fun to recompile the entire program every time one
of the macros is changed. The class macros plus the dynamic class functions
make a fairly independent unit, so this seems logical.
https://bugzilla.gnome.org/show_bug.cgi?id=614413
|
| |
|
|
|
|
|
|
|
| |
Send in a reference to the prototype to JS_NewObject, this
makes sure that the created object contains all properties from
the prototypes. This makes it possible to call Cairo.Context methods
on wrappers created from API created through introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=614413
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
JS_NewObject() does not take a prototype parameter anymore, that has been
split into a different function, JS_NewObjectWithGivenProto(). Passing
JS::NullPtr() as prototype means "Look in the global object for a
prototype that matches the given class" and that is now the only possible
behaviour for JS_NewObject().
Both JS_NewObject() and JS_NewObjectWithGivenProto() have had their
global object parameter made optional, so in the cases where we were
passing JS::NullPtr() there, then we simply leave it out.
https://bugzilla.gnome.org/show_bug.cgi?id=777962
|
| |
|
|
|
|
|
| |
In APIs that now take a JS::HandleObject, we must pass JS::NullPtr()
since JS::HandleObject cannot directly be constructed from NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=751252
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the old unused gjs_parse_args(), and moves
gjs_parse_call_args() into new files jsapi-util-args.cpp and
jsapi-util-args.h.
In order to ensure that JSObjects unpacked from gjs_parse_call_args()
land in GC roots, we need to add some type safety to its variable
arguments. Instead of accepting a JSObject** pointer for the "o" format
character, it must accept a JS::MutableHandleObject.
We can do this (and make the whole thing type safe as well) by using C++
templates instead of C varargs. Now we can issue a compile-time error
when an unknown type is passed in as a return location for an argument,
in particular JSObject**.
This also fixes some undefined behaviour: the old signature of
gjs_parse_call_args() placed the varargs parameter right after the
JS::CallArgs& parameter, and using a reference parameter in va_start() is
undefined. Here's a good explanation of what can go wrong:
http://stackoverflow.com/a/222288/172999
https://bugzilla.gnome.org/show_bug.cgi?id=742249
|
| |
|
|
|
|
|
|
|
|
|
| |
This removes gjs-internals-1.0.pc and gjs-module.h, and makes all the
module header files private, that were previously installed.
Removes "do not include separately" guards from those files, and makes
sure they are included with quotes instead of angle brackets. Untangles
any header inclusion problems resulting from the removal of gjs-module.h.
https://bugzilla.gnome.org/show_bug.cgi?id=772386
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The layout of the JSFunctionSpec and JSPropertySpec changes in between
SpiderMonkey releases, so using these macros makes our code easier to
port to subsequent releases. It's also safer since we don't have to cast
all the function pointers to JSNative, though sadly that means we do need
to reintroduce JSBool in many places until we switch to mozjs31.
We don't convert JSFunctionSpecs yet because there are no JS_FS macros
for JSPropertyOp-style entries. These are removed, because broken, in a
subsequent SpiderMonkey release, though I'm not sure if it's 31:
https://bugzilla.mozilla.org/show_bug.cgi?id=992977
So, in a subsequent commit we will switch to JSNative property accessors.
Removing the casts has exposed a bug in imports._gi.add_interface() which
probably crashes if you try to call it from JS. This bug is not fixed
with this commit.
https://bugzilla.gnome.org/show_bug.cgi?id=742249
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting with the functions defined in jsapi-util.h's
GJS_DEFINE_PRIV_FROM_JS macro, we convert the JSObject pointers there to
JS::HandleObjects, in order to be able to pass them to
JS_GetInstancePrivate() in mozjs31 which will only accept HandleObjects.
We work backwards from there, in a huge cascade, changing JSObject* to
JS::HandleObject in all function argument types that call into those
functions, and rooting the objects with JS::RootedObject where they are
created.
This is mostly straightforward but object_init_list in object.cpp needed
some extra attention. Normally objects are rooted for the duration of a
scope. In this case, we used a GSList to keep track of the objects past
the end of the scope, so they could be fetched again in the GObject's
construct() vfunc. With the normal rooting, that does not work because
the objects can be moved or GC'd after the original scope ends. Instead
we have to use JS_AddNamedObjectRoot() and JS_RemoveObjectRoot(). This
can be changed to a nicer API in mozjs31, JS::PersistentRooted.
https://bugzilla.gnome.org/show_bug.cgi?id=742249
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
JS_ARGV, JS_SET_RVAL are gone in spidermonkey 31, and JS_THIS will be going away in the future
https://bugzilla.gnome.org/show_bug.cgi?id=742249
|
| |
|
|
|
|
|
|
| |
For wrapper objects that hold thread-safe or unique C structures,
set the appropriate flag to send the finalizer to the background
thread, so that we don't block the mainloop more than necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=725024
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=710878
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=710878
|
