This commit adds two new types of scopes:
- DisallowJavascriptExecutionScope
- AllowJavascriptExecutionScope
The first one can be used to prevent execution of JavaScript
(with customizable behavior on an attempt of executing JS, eg.
crashing the process); while the second one can be constructed
from the first to temporarily enable executing JS.
These are useful for "value serializers" to prevent user defined objects
from causing unintended behavior.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
MSVC and Itanium C++ ABIs agree that for simple inheritance the basic structure of a vtable contains metadata fields at a "negative offset" from the vtable pointer, and at zero or positive offsets come the virtual function pointers in the order of declaration. The only difference between the two is that MSVC only places the virtual deleting destructor in the vtable while Itanium ABI places both the deleting and the complete object destructors in it, leading to a vtable that is one pointer larger in Itanium / on Linux. Also MSVC only has a single metadata field instead of two for Itanium. Itanium inlines the base offset into the vtable while MSVC keeps it in what is essentially the entry point into the type info data.
Since the two are so similar, creating a custom vtable on Rust-side is pretty easy and can be done entirely at compile-time, meaning that instances of the class can also be created entirely at compile time. This leads to fully const external strings being possible.
Some fixes around one-byte strings:
- `is_onebyte` was calling the wrong v8 API.
- We didn't have a way to write one-byte strings with uninitialized buffers
- (bonus) The test_string method was quite slow making testing a bit of a pain
Prior to this commit, `v8::NamedPropertyHandlerConfiguration`
and `v8::IndexedPropertyHandlerConfiguration` did not expose the
`definer` hook, or `flags`.
This commit adds these options. In the process of doing this a couple of
other changes were made:
- Bitflag enum consts are now member consts of the related struct.
This is done because PropertyHandlerFlags has conflicts with
PropertyAttribute.
- PropertyDescriptor gets all C++ introspection methods exposed to Rust.
- NamedPropertyHandlerConfiguration callback types get rustdoc comments.
- IndexedPropertyHandlerConfiguration callback types get rustdoc
comments.
- GenericNamedPropertySetterCallback gets a ReturnValue parameter, to
signal trap passthrough.
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Reproduces #1226 and denoland/deno#19021
```
// Fails
$ V8_FROM_SOURCE=1 cargo test exception
// Passes
$ V8_FROM_SOURCE=1 cargo test --release exception
```
We bisected this and this problem first appeared with V8 v11.2 upgrade. After further
bisects we established that v8/v8@1f349da#diff-de75fc3e7b84373d94e18b4531827e8b749f9bbe05b59707e894e4e0ce2a1535
is the first V8 commit that causes this failure. However after more investigation we can't
find any reason why that particular commit might cause this problem.
It is only reproducible in debug build, but not release build. Current working theory
is that it is a Rust compiler bug as changing the optimization level for this code
makes the bug go away. This commit should be considered a band-aid that works
around the problem, but doesn't fix it completely. We are gonna go with it as it
unblocks un on day-to-day work, but ultimately we should track it down (or wait
for another Rust upgrade which might fix it?).
---------
Co-authored-by: Bert Belder <bertbelder@gmail.com>
Changes signature of "FunctionTemplate::build_fast" to allow
to pass "CFunctionInfo" explicitly. If it's not passed explicitly,
it's still autogenerated.
Adds bindings for:
- v8::Context::GetContinuationPreservedEmbedderData
- v8::Context::SetContinuationPreservedEmbedderData
These APIs are available on the "HandleScope".
---------
Co-authored-by: Bert Belder <bertbelder@gmail.com>
Removing this garbage collection trigger removes the guarantee that
"regular" FinalizerCallbacks will be called before the isolate goes away.
It is fine as both spec and V8 do not provide this guarantee and we were
overly strict in this case.
The pointer returned by `ArrayBuffer::data` might be null if the
backing store has zero length, but the return type `*mut c_void` does
not force the user to consider this case. This change makes the return
type `Option<NonNull<c_void>>`, which is semantically equivalent, but
which forces users of the API to handle the `None` case.
This PR is the `ArrayBuffer` counterpart to #817.
This is a breaking API change.
This method, introduced in V8 10.9, makes it so an `ArrayBuffer`
object is impossible to detach unless a specific detach key is passed
to the `detach` method. Such `ArrayBuffer`s still count as detachable
as per the `ArrayBuffer::is_detachable` method, but otherwise behave
much like WebAssembly memories.
This commit adds "v8::Module::get_stalled_top_level_await_message" API
that allows to retrieve a vector of tuples with handles to v8::Module and v8::Message.
This information can be used to display a nice error when event loop runs out
of work to do but there are still unresolved promises.
This commit adds "v8::Isolate::snapshot_creator_from_existing_snapshot" API,
that allows to create a new snapshot from already existing snapshot.
Following APIs were added as well:
"v8::Context::from_snapshot"
"v8::Isolate::add_context"
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: Bert Belder <bertbelder@gmail.com>
This commit removes "v8::SnapshotCreator" in favor of
"v8::Isolate::snapshot_creator" API. All methods from
"v8::SnapshotCreator" are now available on the "v8::Isolate".
If a method is called and isolate was not set up as a snapshot
creator then it will panic.
This commit gets rid of long standing unsoundness in typing
that allowed to easily induce a panic or segfault if a user didn't
use snapshot creator API properly.
Check that it actually performs the expected operation (adding two
numbers) because it didn't - the callback's function prototype was
wrong. V8 always passes the receiver object as the first parameter.
Currently, when a finalizer callback is registered, it is not
guaranteed to be called if there is a global reference to the
corresponding object that survives the isolate. This is because the
finalizer callback takes a `&mut Isolate`, and so it must be called
before the isolate is fully destroyed, but all existing globals
(including possibly the one being currently finalized) are still
usable while there still exists a mutable reference to the isolate.
However, there are still use cases for having finalizers that are
guaranteed to run regardless of any remaining globals, but that don't
require any interaction with the isolate. This change adds them.
This change also changes the context annex to use a guaranteed
finalizer, fixing a bug with context slots not being freed if there
were any globals to the context at the time the isolate is dropped.
property_attribute previously had an addition operator overload which
doesn't make much sense in comparison to the corresponding V8
enumeration. This changes that to a bitor overload.
Signed-off-by: Darshan Sen <raisinten@gmail.com>
This change allows the customization of the behavior of
v8::Object::GetOwnPropertyNames() and v8::Object::GetPropertyNames() by
accepting all the options that the raw V8 API supports.
Signed-off-by: Darshan Sen <raisinten@gmail.com>
This change adds support for weak handles that don't prevent GC of the
referenced objects, through the `v8::Weak<T>` API. A weak handle can
be empty (if it was created empty or its object was GC'd) or
non-empty, and if non-empty it allows getting its object as a global
or local.
When creating a `v8::Weak` you can also set a finalizer that will be
called at some point after the object is GC'd, as long as the weak
handle is still alive at that point. This finalization corresponds to
the second-pass callback in `kParameter` mode in the C++ API, so it
will only be called after the object is GC'd. The finalizer function
is a `FnOnce` that may close over data, and which takes a
`&mut Isolate` as an argument.
The C++ finalization API doesn't guarantee _when_ or even _if_ the
finalizer will ever be called, but in order to prevent memory leaks,
the rusty_v8 wrapper ensures that it will be called at some point,
even if it's just before the isolate gets dropped.
`v8::Weak<T>` implements `Clone`, but a finalizer is tied to a single
weak handle, so its clones won't be able to keep the finalizer alive.
And in fact, cloning will create a new weak handle that isn't tied to
a finalizer at all. `v8::Weak::clone_with_finalizer` can be used to
make a clone of a weak handle which has a finalizer tied to it.
Note that `v8::Weak<T>` doesn't implement `Hash`, because the hash
would have to change once the handle's object is GC'd, which is a big
gotcha and would break some of the algorithms that rely on hashes,
such as the Rust std's `HashMap`.
