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.
this warning only occurs when using the library as a dependency.
warning: unused return value of `Box::<T>::from_raw` that must be used
--> /rusty_v8/src/scope.rs:1092:16
|
1092 | unsafe { Box::from_raw(root) };
| ^^^^^^^^^^^^^^^^^^^
|
= note: call `drop(Box::from_raw(ptr))` if you intend to drop the `Box`
= note: `#[warn(unused_must_use)]` on by default
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
By default, copying a file will preserve its mode and ownership
attributes.
This is an issue when copying the V8 archive from a read-only
filesystem since the archive file also becomes read-only, so
subsequent builds will fail.
We now create a new destination file and copy the content of the archive
to it, this ensures the destination file has the default attributes.
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>
