`napi_call_function` should use our equiv of NAPI_PREAMBLE (`&mut Env`
instead of `*mut Env`) since it needs to set error codes based on
whether the body of the function raised a JS exception.
Fixes: https://github.com/denoland/deno/issues/26282
Fixes #24740.
Implements the `uv_mutex_*` and `uv_async_*` APIs.
The mutex API is implemented exactly as libuv, a thin wrapper over the
OS's native mutex.
The async API is implemented in terms of napi_async_work. As documented
in the napi docs, you really shouldn't call `napi_queue_async_work`
multiple times (it is documented as undefined behavior). However, our
implementation doesn't have any issue with this, so I believe it suits
our purpose here.
Part of #20613.
If a node addon is using the legacy `napi_module_register` on ctor
approach to module registration, we have to store the registered module
so that other threads can load the addon (because `napi_module_register`
will only be called once per process).
Fixes #23493.
What was happening here was that napi-rs was freeing the napi reference
([here](19e3488efc/crates/napi/src/bindgen_runtime/mod.rs (L62)))
during its finalize callback (which we call
[here](fb31eaa9ca/cli/napi/js_native_api.rs (L132))).
We then were [reading the `ownership`
field](fb31eaa9ca/cli/napi/js_native_api.rs (L136))
of that freed reference.
For some reason on arm macs the freed memory gets zeroed, so the value
of `ownership` was `0` when we read it (i.e. it was
`ReferenceOwnership::Runtime`). We then freed it again (since we thought
we owned it), causing the segfault.
1. Generally we should prefer to use the `log` crate.
2. I very often accidentally commit `eprintln`s.
When we should use `println` or `eprintln`, it's not too bad to be a bit
more verbose and ignore the lint rule.
