A subtle unsoundness / undefined behaviour made its way into the fairly recently added ExternalOneByteStringResource object: The as_str API is not sound as the data inside may be be Latin-1, not ASCII.
As the API was not used anywhere in deno or deno_core, I opted to simply remove it and replace it with an as_bytes API. I also modified the test to showcase the Latin-1 string case and added copious notes and explanations around the code to make sure this doesn't accidentally happen again. The likely reason why the API originally slipped in is because the OneByteConst has this API where it is safe because the OneByteConst creation checks the data for ASCII-ness.
I also tried to add an API to extract an Option<&'static OneByteConst> from an &ExternalOneByteStringResource but run into rust-lang/rust#119618 ie. OneByteConst is actually duplicating the vtables... which is not great.
This commit updates APIs related to named and indexed property
handlers to not use deprecated V8 APIs. Main change is the change
of return value in callbacks that now requires to return v8::Intercepted enum.
Towards #1478
1. [[exceptions] Unify pending and scheduled exceptions](https://chromium-review.googlesource.com/c/v8/v8/+/5050065)
Reset no longer clears exception if it was rethrown. The test had to be adjusted for the same.
2. [[api] Allow passing CppHeap on Isolate creation](https://chromium-review.googlesource.com/c/v8/v8/+/4989254)
`AttachCppHeap` was deprecated but the alternative of passing `CppHeap` via Isolate CreateParams hard crashes (SIGSEGV). There are no tests for this in V8 and it seems the [Chromium CL](https://chromium-review.googlesource.com/c/chromium/src/+/4992764) is also crashing. For now I've just suppressed the deprecation warning until the crash is fixed in V8.
3. v8::Serializer impl must not throw more than one exception.
I changed `get_shared_buffer_id()` to not throw and return `None`. V8 internally calls data clone error when it's the SAB is not clonable.
Other changes:
- `v8::ScriptCompiler` size increased by 3 words with `v8::ScriptCompiler::CompilationDetails`.
- `v8::ObjectTemplate::SetAccessor` & `v8::ObjectTemplate::SetAccessorProperty` signature changed and also deprecated.
- `v8::Context::SetContinuationPreservedEmbedderData` deprecated. Use `v8::Isolate::GetContinuationPreservedEmbedderData` instead.
- `GetStalledTopLevelAwaitMessage` deprecated. Use `GetStalledTopLevelAwaitMessages` instead.
- `v8::Isolate::AttachCppHeap` deprecated. Set the heap on Isolate creation using CreateParams instead.
- `v8::ScriptOrigin` deprecated. Use constructor without the isolate.
- `v8::SnapshotCreator` is deprecated. Use the version that passes CreateParams instead.
- `v8::Isolate` assertion failures.
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Due to the automatic entry and exit behavior of Isolate upon creation and drop, it is crucial to ensure that v8::OwnedIsolate instances are dropped in the reverse order of their creation. Dropping them in the incorrect order can result in the corruption of the thread-local stack managed by v8, leading to memory corruption and potential segfaults. This introduces a check to verify the `this == Isolate::GetCurrent()` requirement before invoking the exit function. If the requirement is not met, a clean panic is triggered to provide explicit error handling instead of allowing silent memory corruption.
Add v8::ValueSerializerImpl::{has_custom_host_object,is_host_object}
equivalents for v8::ValueSerializer::Delegate::{HasCustomHostObject,IsCustomHostObject}.
This enables serializing custom host objects without embedder fields.
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.
