Ninja and GN are upgraded to the version specified in V8's `DEPS` file
as of V8 11.0.226.2.
As part of this upgrade, native binaries for linux-arm64 and mac-arm64
were added to the repository, and some directories were renamed to make
the overall naming scheme more consistent.
The following libraries and tools are upgraded to the version specified
in V8's `DEPS` file as of V8 11.0.226.2:
* build
* buildtools
* clang
* jinja2
* markupsafe
* trace_event
* zlib
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.
