summaryrefslogtreecommitdiff
path: root/gjs/jsapi-dynamic-class.cpp
Commit message (Collapse)AuthorAgeFilesLines
* maint: Update includes to match new version of IWYUPhilip Chimento2022-11-151-1/+3
|
* js: Various functions moved out of jsapi.hPhilip Chimento2022-08-071-1/+3
| | | | | | | | | | | - js/CallAndConstruct.h: Now contains JS::Call, JS::Construct, and related - js/Debug.h: Already existed, but now contains JS_DefineDebuggerObject - js/GlobalObject.h: Now contains JS::CurrentGlobalOrNull - js/PropertyAndElement.h: Now contains APIs for getting, setting, and defining properties, as well as array elements - js/ScriptPrivate.h: Now contains JS::GetScriptPrivate/SetScriptPrivate - js/Stack.h: Now contains APIs that have to do with the call stack
* Remove JSPROP_GETTER and JSPROP_SETTER usageEvan Welsh2022-01-161-3/+0
| | | | | | | | These flags are now automatically determined based on whether the passed getter or setter is null. Changeset: https://phabricator.services.mozilla.com/D116091 See: https://bugzilla.mozilla.org/show_bug.cgi?id=1713083
* JS_GetClass is now JS::GetClassEvan Welsh2022-01-161-1/+2
| | | | See https://bugzilla.mozilla.org/show_bug.cgi?id=1663365
* Convert JS_New usage to JS::ConstructEvan Welsh2021-10-081-1/+6
| | | | | | JS_New was removed in favor of JS::Construct. See https://bugzilla.mozilla.org/show_bug.cgi?id=1491055
* *: Fix spelling mistakes found by codespellBjörn Daase2020-11-291-2/+2
|
* maint: Convert all existing license/copyright comments to SPDX formatPhilip Chimento2020-10-041-22/+3
| | | | | | | | 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.
* js: Update header includes for SpiderMonkey 78Philip Chimento2020-08-111-0/+1
| | | | | | | Adapt the IWYU processing script to the contents of the new version of js/TypeDecls.h, and adjust the includes where necessary. See: GNOME/gjs#329.
* js: Refactor Array-related JSAPI calls.Evan Welsh2020-08-111-0/+1
| | | | | | | | | | - <js/Array.h> and <js/ValueArray.h> are new headers. - Rename JS_NewArrayObject to JS::NewArrayObject. - Rename JS_GetArrayLength to JS::GetArrayLength. - Rename JS_IsArrayObject to JS::IsArrayObject. - Rename JS::AutoValueArray to JS::RootedValueArray. See: GNOME/gjs#329
* maint: Use C++17 attributesPhilip Chimento2020-08-051-4/+1
| | | | | | | | | | | | | 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
* jsapi-dynamic-class: Don't predefine properties with RESOLVING flagPhilip Chimento2020-07-271-27/+6
| | | | | | | | | This will be unsupported in SpiderMonkey 78. It seems that in these particular cases, we can pre-define these properties on classes with resolve hooks, without using the RESOLVING flag because the resolve hook doesn't try to access any of these. See: GNOME/gjs#329
* js: Fix header includes according to IWYUPhilip Chimento2020-05-201-1/+0
| | | | | | | This updates all the includes according to what IWYU suggests. In a few cases we move a typedef down in order to avoid IWYU wanting a forward declaration, or use a JS::Heap<T>{braced initializer} in order to avoid an implicit std::move.
* js: Remove jsapi-wrapper.hPhilip Chimento2020-01-191-1/+13
| | | | | | | | | | | | | 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>.
* js: Various API renamesPhilip Chimento2020-01-191-3/+2
| | | | | These are straightforward renames that happened between SpiderMonkey 60 and 68.
* js: Rename "compartments" to "realms"Philip Chimento2020-01-191-1/+1
| | | | | | | | | | | | | | In SpiderMonkey 68, a "realm" is the term for the environment belonging to a particular global object, so when you enter the "realm" of a global object you are executing code with that object as the global object. "Compartments" are still a thing but they are now more focused on security, and are used for isolating code in different browser tabs in Firefox, for example. All code in GJS except the debugger and the coverage collector is run within the same compartment. Some APIs that previously operated on a global object that was passed in, now operate on the current realm.
* js: Remove requestsPhilip Chimento2020-01-191-4/+0
| | | | | | JSAutoRequest, JS_BeginRequest(), and JS_EndRequest() are no longer necessary in SpiderMonkey 68. We can just remove them wherever they appear.
* cairo: Add type checking to Path, Pattern, and SurfacePhilip Chimento2019-10-301-0/+35
| | | | | | | | | | | | | | | | | Previously, passing the wrong kind of object where a Cairo.Path, Cairo.Pattern (subclass), or Cairo.Surface (subclass) was expected, would crash. This adds type checking to avoid these crashes. The normal way to do this would be with JS_HasInstance(), but since Cairo.Pattern and Cairo.Surface are abstract classes, that won't work. JS_HasInstance() takes a constructor, and abstract classes don't have a constructor. Instead, we have to check the passed-in object's prototype chain. It turns out there isn't a JSAPI function to do that, so we add gjs_object_in_prototype_chain() for this purpose. In addition we add missing error checking in a few places. Closes: #49.
* jsapi-dynamic-class: Switch to RAII classesPhilip Chimento2019-10-281-32/+17
| | | | | | | | We are going to refactor this anyway when we remove JSRequest in SpiderMonkey 68. So, use RAII classes here and get rid of the gotos. The comment at the top of the function about using 'volatile' to force the variables to be collected by the GC has been inaccurate since SpiderMonkey switched to an exact garbage collector several years ago.
* maint: Fix header includes once and for allPhilip Chimento2019-06-081-9/+8
| | | | | | | | | | | | | | | | | | 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.
* util: Remove util/glibPhilip Chimento2019-06-081-1/+0
| | | | | | This file only had one function in it. It's not clear why this util file is "glib" and the other file with one function in it is "misc". Merge them both into "misc".
* jsapi-class: Make parameter const-correctPhilip Chimento2018-12-211-16/+9
| | | | | gjs_init_class_dynamic() should take a const JSClass* pointer, since it is not modified, and JS_InitClass() takes a const pointer as well.
* jsapi-class: Fix commentPhilip Chimento2018-12-211-1/+1
| | | | | Our two weapons are fear and surprise ... and ruthless efficiency ... our *three* weapons are...
* context: Move atoms to a separate classPhilip Chimento2018-11-051-8/+9
| | | | | | This moves the atoms (interned strings) from GjsContextPrivate to a separate class, so that we can decouple them from GjsContext, since in some cases we will want to use them only with the SpiderMonkey API.
* js: Introduce annotations for using return valuesPhilip Chimento2018-10-301-0/+2
| | | | | | | | | | | | | | | | | | | 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".
* js: Misc mozjs60 API changesPhilip Chimento2018-07-281-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | - An argument that we didn't use was removed from the JSFinalizeCallback signature - JS_SetLocaleCallbacks API changed (is JSRuntime coming back again?) - Giving a JSVERSION to a compartment or CompileOptions is not supported anymore - Use JS::CurrentThreadIsHeapCollecting() instead of our hacky workaround in GC - JS::PromiseRejectionHandlingState now is in the JS namespace - JS::Value is now incompatible with C-linkage, so any function returning one must be moved outside G_BEGIN_DECLS/G_END_DECLS - JSPROP_SHARED is gone - Defining a property with getter and setter now doesn't take a JS::Value See: #161
* object: Remove getProperty/setProperty hooksPhilip Chimento2018-05-261-0/+92
| | | | | | | | | | | | | | | | | | | | These hooks are going away in SpiderMonkey 60, so we have to do something different. Instead of intercepting the getProperty/setProperty operations, we lazily define a JS property for each GObject property or field accessed in the resolve hook. This uses the same native-accessor-with-private-data API used in gi/boxed.cpp. Two separate sets of accessors are used for properties and fields, which makes them a bit simpler than the previous code. One behaviour change is that we now can't distinguish whether we're setting a readonly property in strict mode or not. Now we always throw when setting a readonly property; in effect, we treat the property set as if it were always in strict mode. ES6 modules are always treated as strict mode, so this is a change that client code will have to go through anyway when using ES6 modules. Closes: #160
* jsapi-dynamic-class: Use interned strings to link prototypePhilip Chimento2018-01-291-4/+6
| | | | | This saves a lookup of the strings "constructor" and "prototype" in the interned strings table.
* js: Remove unnecessary property getters and settersPhilip Chimento2017-12-291-4/+3
| | | | | | In SpiderMonkey 60, properties that have a value will not be able to have C++ getters and setters. The getters and setters are already unnecessary in all the cases where we use them, so just remove them.
* jsapi-util: Remove jsapi-privatePhilip Chimento2017-10-031-1/+0
| | | | | | | 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.
* error: Use JSProtoKey to get Error constructorPhilip Chimento2017-10-031-1/+1
| | | | | | Instead of looking up the Error prototype by name on the global object when we want to throw an error, use JS_GetClassObject and JSProtoKey to avoid the conversion of string to ID and the property lookup.
* js: New JSClass struct layoutPhilip Chimento2017-07-091-2/+2
| | | | | | | | | | | | Instead of the various operation hooks being members of JSClass directly, now JSClass contains a pointer to a JSClassOps struct. The JSClassOps instead contains the function pointers to the operation hooks. For importer.cpp, we still use the internal js::Class instead of JSClass. This also contains a pointer to another struct, JSObjectOps, which we still need for our internal lazy enumerate hook. https://bugzilla.gnome.org/show_bug.cgi?id=784196
* js: Update obsolete commentsPhilip Chimento2017-07-091-5/+2
| | | | | | | These comments were previously correct, but have become incorrect in SpiderMonkey 45. https://bugzilla.gnome.org/show_bug.cgi?id=784196
* js: Set JSPROP_RESOLVING when defining propertiesPhilip Chimento2017-07-091-2/+24
| | | | | | | | JS_DefineProperty() can now call into a class's resolve hook, so when pre-defining properties on classes with resolve hooks we have to include JSPROP_RESOLVING in the flags so that the resolve hook is not called. https://bugzilla.gnome.org/show_bug.cgi?id=784196
* js: Global object is implicit in many functionsPhilip Chimento2017-07-091-3/+1
| | | | | | | In many function calls where you had to pass in a global object, it is now implicit and will use the global for the current scope. https://bugzilla.gnome.org/show_bug.cgi?id=784196
* js: Don't pass global object to JS_NewObject functionsPhilip Chimento2017-04-171-3/+2
| | | | | | | | This is optional, and will become disallowed in SpiderMonkey 45. No change in functionality, because leaving it out already causes JS to get the global object internally. https://bugzilla.gnome.org/show_bug.cgi?id=781429
* maint: Use correct mode lines in all filesPhilip Chimento2017-04-161-1/+1
| | | | | | | | | 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.
* jsapi-util: Split off class stuff into jsapi-class.hPhilip Chimento2017-04-131-0/+1
| | | | | | | | | 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
* jsapi-dynamic-class: Use JS_LinkConstructorAndPrototype()Philip Chimento2017-04-111-6/+1
| | | | | | | Small cleanup; there is a function in the JSAPI that does exactly this, automatically with the right flags. https://bugzilla.gnome.org/show_bug.cgi?id=614413
* importer: Switch back to lazy enumerationPhilip Chimento2017-02-141-1/+1
| | | | | | | | | | | | | | | | | | | Lazy enumeration is still available through the jsfriend API in js::Class, which is really JSClass but with some extra fields that are masked in the public version. In addition, JSNewEnumerateOp has changed somewhat, compared with SpiderMonkey 31. Instead of the enumerate callback being called incrementally for each property, now it is just called once the first time an object's properties are enumerated, and you have to fill in the passed-in JS::AutoIdVector with any names of lazy properties. This changes the behaviour slightly, since the AutoIdVector already contains any enumerable property names that the JS engine already knows about, before the enumerate callback is called! So we now get byteArray, etc. when we enumerate the importer. https://bugzilla.gnome.org/show_bug.cgi?id=777962
* js: JSNative accessors in JS_DefineProperty()Philip Chimento2017-02-141-4/+3
| | | | | | | | | In JS_DefineProperty(), the getter and setter parameters must now be of type JSNative. We have already switched to JSNative accessors everywhere, but there are a few macros that must change in order to ensure everything is cast to the right type. https://bugzilla.gnome.org/show_bug.cgi?id=777962
* js: Adapt to new JS_NewObject() APIPhilip Chimento2017-02-141-1/+1
| | | | | | | | | | | | | | 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
* js: Refactor gjs_object_*_property()Philip Chimento2017-01-261-4/+3
| | | | | | | | | | | | | | | | | | | | | | | 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
* dynamic class: Check if prototype is NULLPhilip Chimento2017-01-131-8/+12
| | | | | | | | | | | | | | This fixes a regression introduced in commit a2fdf358207d075e9cbc6d78895f87b4e5a72bea. If the prototype passed to the dynamic class's constructor is NULL, then we have to call JS_NewObject() to get a default prototype, instead of JS_NewObjectWithGivenProto(). Otherwise the object has _no_ prototype at all. Includes a regression test that would have caught this bug. https://bugzilla.gnome.org/show_bug.cgi?id=776966
* js: Use JS_NewObjectWithGivenProtoPhilip Chimento2017-01-091-1/+1
| | | | | | | | | | In mozjs38, JS_NewObject() doesn't take a prototype JSObject anymore; instead, JS_NewObjectWithGivenProto() is used for that purpose. The behaviour of JS_NewObject() is changed so that it looks for a default prototype, which is the same as passing JS::NullPtr() as the proto parameter in mozjs31. https://bugzilla.gnome.org/show_bug.cgi?id=776966
* jsapi-util-error: Allow throwing custom 'name' propertyPhilip Chimento2016-12-271-1/+1
| | | | | | | | | | | | | | | | | According to MDN [1], an idiomatic way to indicate a custom error is by setting the 'name' property: var e = new Error('Malformed input'); // e.name is 'Error' e.name = 'ParseError'; throw e; // e.toString() would return 'ParseError: Malformed input' Add an extra 'name' argument to gjs_throw_custom() to allow this. If 'name' is NULL, then the previous behaviour is maintained. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/name https://bugzilla.gnome.org/show_bug.cgi?id=730101
* js: Adapt to new JS_DefineProperty APIPhilip Chimento2016-12-091-6/+8
| | | | | | | | | | | | | | | | | The setter and getter parameters now come after the flags, and passing NULL for them is no longer required, since they have default values in mozjs31. I believe that NULL (use the object's class's default setters and getters) is different from JSPropertyStub and JSStrictPropertyStub, so I left those in where they occurred. In mozjs31 a bunch of overloads were defined, where you can pass JS::HandleObject, JS::HandleString, int32_t, uint32_t, and double directly to JS_DefineProperty() instead of only JS::HandleValue. This allows us to get rid of some roots in our code where we created a JS::RootedValue for the sole purpose of passing some value to JS_DefineProperty(). https://bugzilla.gnome.org/show_bug.cgi?id=751252
* js: Use HandleValueArray as function paramPhilip Chimento2016-12-091-5/+4
| | | | | | | | | | | | | | | JS::HandleValueArray is a useful way to pass arrays of arguments around, has handy constructors such that you can pass in JS::CallArgs directly. Therefore we refactor some functions to take it instead of argc, argv. This will make the following commit easier where we adapt to the new APIs of JS_New(), JS_CallFunction(), etc. which require JS::HandleValueArray. This requires some changes in the closure callback marshal as previously we were passing in an array that was longer with some empty elements at the end, and relying on argc not to fall off the end. Now that there is no argc parameter, we have to rearrange things a bit in that function. https://bugzilla.gnome.org/show_bug.cgi?id=751252
* js: Root gjs_init_dynamic_class()Philip Chimento2016-10-261-17/+12
| | | | | | | Starting in jsapi-dynamic-class.cpp and working backwards, we cause another cascade of GC rooting changes. https://bugzilla.gnome.org/show_bug.cgi?id=742249
* js: Add convenience gjs_object_require_property_valuePhilip Chimento2016-10-251-13/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | This adds several functions in an overloaded gjs_object_require_property_value() family, as well as a gjs_object_require_converted_property_value() that can be overloaded when the opportunity arises. One operation that is done many times across the codebase is to call gjs_object_require_property() and then typecheck the JS::Value that it returns, throwing a custom exception if the property was the wrong type. We introduce gjs_object_require_property_value() which takes a pointer to whatever type we expect in the JS::Value, and takes care of all the rooting and exception throwing. Basically it calls the equivalent of isWhateverType() and toWhateverType() while skipping JSString * in favour of returning a UTF-8 encoded string. For not only type-checking but also converting a JS::Value of the wrong type to the requested type, there is gjs_object_require_converted_property_value(). Currently in the codebase this operation is only done on one type, uint32, but it can be overloaded with more types later. This reduces a lot of code duplication that would otherwise all have to be converted to rooting by hand in the next commit. https://bugzilla.gnome.org/show_bug.cgi?id=742249
* js: Root gjs_object_require_property()Philip Chimento2016-10-251-6/+6
| | | | | | | | | | | | Starting out with gjs_object_require_property(), we do another cascade of GC rooting changes. This requires making some changes to the private structs of Boxed and Fundamental. Since they contain members of type jsid, which are subject to garbage collection, those members must be traced. JSClass provides a trace callback for this purpose. https://bugzilla.gnome.org/show_bug.cgi?id=742249
View Lorry Controller Status