* add "run_script" for "Env"
* Apply suggestions from code review
use `AsRef<str>` instead of `&str`
Co-authored-by: LongYinan <lynweklm@gmail.com>
* use `AsRef<str>` instead of `&str`
Co-authored-by: LongYinan <lynweklm@gmail.com>
The third argument to `napi_create_async_work` (async_resource_name)
should be a `napi_value` that corresponds to a null-terminated utf-8
string.
This resolves errors running Next.js with GraalVM.
oracle/graal#5582oracle/graal#5581
Notice from the n-api docs that the data returned from
`napi_get_typedarray_info` is already adjusted by the byte offset.
https://nodejs.org/api/n-api.html#napi_get_typedarray_info
This means that when `as_ref`/`as_mut` apply the byte offset, the
offset is in practice applied twice.
This wasn't caught in tests because no test tried to modify a typed
array with a byte offset, and the test didn't us the typed array
structs, only `JsTypedArray`. If you want, I can modify the rest of the
functions in examples/napi-compt-mode/src/arraybuffers.rs
and the matching tests, to test all typed arrays.
IMO the `byte_offset` field can be removed entirely from the struct,
but I wanted to submit a minimal PR.
we need this to be able to safely drop an struct,
that makes use of an async task.
the drop function needs to be able to call `.abort()`
on the join handle to avoid memory corruption and undefined bahviour.
* fix leaked napi refcount in `Buffer` when cloning
Cloning unconditionally increased the refcount in `Buffer::clone`, but only called `napi_reference_unref` on dropping the last Buffer (the one with `strong_count == 1`). This means that the refcount will never drop back to zero after cloning, leaking the Buffer.
This commit changes it to also unconditionally unref the buffer.
* fix multiple sources of UB in `Buffer`
- `slice::from_raw_parts` may never be created with a null pointer, but `napi_get_buffer_info` was not sufficiently checked → UB when passing an empty Buffer
- `&'static mut [u8],` is invalid, as it certainly doesn't live for `'static`
Switching to `NonNull<u8>` and a `len` field fixes both of these.
- I also don't really understand how the `impl ToNapiValue for &mut Buffer` could have been sound. It creates an entirely new `Arc`, but reuses the same `Vec` allocation, leading to... a double free of the `Vec` on drop? I have replaced it with a simple call to `clone` instead.
* remove overcomplicated bool and drop impl
As far as I can tell, by just removing the bool and letting the drop code do its thing we clean up correctly in all cases. Because `napi_create_external_buffer` gets an owned `Buffer` attached to it via the Box, we can rely on `from_raw` retrieving it in the `drop_buffer` function.
This patch introduces a new macro: `either_n!` that generates the types
`Either{n}` where $3 \leq n \leq 26$. Manual implementations for
`Either3`, `Either4` and `Either5` are removed by this patch too.
The `either_n!` macro is quite classical. There is no particular
trick, except `count_idents!` which simply turns, e.g. `A, B, C` into
`3`. This macro is used by `either_n!` to implement the
`debug_assert!` inside `from_napi_value`.
This patch is the sequel of
https://github.com/napi-rs/napi-rs/pull/1195 where `ToNapiValue` and
`FromNapiValue` are implemented for all `Vec<T>` where `T` is a 8 or
16 bits number.
`napi` only supports numbers in 16 and 32-bits. To support Rust
numbers with 8 and 16-bits, we can cast them to 32-bits. To convert
from 8 and 16-bits to 32-bits, we use their `Into` implementation. To
convert from 32-bits to 8 and 16-bits, we use their `TryInto`, we
should theorically not fail, but in case of, an `except` message is
appended.
The code has also been re-indented as it was containing a mix of 2
spaces, 4 spaces and tabs identation.
