This workflow will bump a version and create a tag which will kick-off another
build that will build release binary archives and create a GH release.
Maintainer is still responsible for building artifacts on M1 mac.
current zlib 1.2.12 is vulnerable to CVE-2022-37434 as documented on zlib website with details at https://nvd.nist.gov/vuln/detail/CVE-2022-37434. This resolves vulnerability by going to zlib 1.2.13
Use `std` functionality where possible. Only size_t needs
to be defined like was done with the `intptr_t` type before.
Also unifies the usage of `std::os::raw` types that where
already defined in the support module.
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.
In #1103, the `ArrayBuffer::was_detached` method was added to rusty_v8
to fill a gap in the C++ API, and it was implemented using the
internal `v8::Utils::OpenHandle`. Since then, a `WasDetached` method
was added to `ArrayBuffer` in V8 10.9. This PR updates the
implementation to use that.
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.
