Before attempting to load a module, each provided resolver must be given an
opportunity to examine the name of the requested module without actually
loading it so as to canonicalize it, in case a module can be referred to by
multiple names.
Then, modules are loaded and cached by their canonical name.
JerryScript-DCO-1.0-Signed-off-by: Gabriel Schulhof [email protected]
Since modules behave differently depending on whether this feature is on or off
we should have a job that runs with the feature turned on.
JerryScript-DCO-1.0-Signed-off-by: Gabriel Schulhof [email protected]
By using constructors/destructors we unify the case of static linking with
that of dynamic linking, and we reuse the build flag FEATURE_INIT_FINI. Using
constructors/destructors also allows us to cover the case where library
constructor/destructor functionality is unavailable, because we can expose the
module registration/unregistration functions as global symbols, to be called
explicitly from within the application.
Fixes https://github.com/jerryscript-project/jerryscript/issues/1952
JerryScript-DCO-1.0-Signed-off-by: Gabriel Schulhof [email protected]
This extension provides the following facilities:
- registering modules,
- module resolvers, and
- an API for retrieving a module instance given its name.
A module is defined as a global static structure containing a pointer
to a string which is the name of the module, and a pointer to a function
which will be called when an instance of the module is needed.
A module resolver is a function that accepts a string holding the name
of the module and returns a `jerry_value_t` in an out-parameter and
`true` if the module was found, or `false` if it was not. If it returns
`true` and the out-parameter has the error flag set then the API will
pass it through without caching.
This extension provides a built-in module resolver which attempts to
load modules that follow the above module definition.
The API provided by this extension invokes all module resolvers it
receives in sequence to attempt to resolve the name of a single module.
After one resolver returns `true` and a `jerry_value_t` that represents
the module the API stops iterating over the remaining resolvers and
caches the value if its error flag is not set. It then returns the
`jerry_value_t`. The API will return a `jerry_value_t` containing an
error indicating that the module was not found if it reaches the end of
the list of resolvers. The error it returns has an extra property
`"moduleName"` the value of which is a string containing the name of the
module that the API was asked to resolve.
JerryScript-DCO-1.0-Signed-off-by: Gabriel Schulhof [email protected]
`jerry_has_property ()` and `jerry_has_own_property ()` are inconsistent
in that they squash their return value into a `bool` when in fact it is
a `jerry_value_t`, thereby giving the wrong impression that a property
is there when it isn't and encouraging the leaking of `jerry_value_t`s
by disguising them as `bool`s.
Fixes https://github.com/jerryscript-project/jerryscript/issues/1859
JerryScript-DCO-1.0-Signed-off-by: Gabriel Schulhof [email protected]
This approach has the benefit that it does not require any *a priori*
initialization, and that each context pointer is identified by the way
in which it was created. Additionally, retrieving the context pointer
now requires that the entity responsible for creating/destroying it
(the manager) be given. Since managers are stored in global static
const structures, they should not normally be visible across source
files, and thus there should be no danger that a context item will be
retrieved by the wrong manager and thus cast into the wrong data type.
Since the items are stored in a linked list, their number will be
limited to exactly as many as are needed for a given context, with the
caveat that storing too many on a context will cause slow retrieval.
Thanks @mhdawson for the idea!
Fixes https://github.com/jerryscript-project/jerryscript/issues/1845
JerryScript-DCO-1.0-Signed-off-by: Gabriel Schulhof [email protected]
This modification makes it possible to initialize a context in such a
way that a `void *` pointer is stored inside the context and is made
available via a new `jerry_get_user_context()` API.
The pointer is initialized via a new `jerry_init_with_user_context()`
API, which calls the existing `jerry_init()`, after which it sets the
value of the new `user_context` element in the `jerry_context_t`
structure using the context allocation callback provided as the second
parameter to the new `jerry_init_with_user_context()` API. The location
of the cleanup function responsible for deallocating the pointer created
by the context allocation callback is provided as the third parameter.
This location is stored in the context along with the pointer itself.
When a context is discarded via `jerry_cleanup()`, the user context
cleanup function is called to dispose of the pointer stored within the
context.
The semantics behind the API are such that it is now possible to choose
for each context an agent which manages arbitrary user data keyed to the
given context. The agent must be chosen at context instantiation time
and cannot be changed afterwards, remaining in effect for the lifetime
of the context.
Fixes#1717
JerryScript-DCO-1.0-Signed-off-by: Gabriel Schulhof [email protected]
Gabriel "_|Nix|_" Schulhof