The `is_sync::<T>()` runtime check relied on implicit specialization via
`Copy`/`Clone` array behavior, which has changed in Rust 1.86+.
`UserDataRef` always taking an exclusive lock even for `Sync` userdata,
preventing concurrent shared borrows.
With the `send` feature flag enabled, userdata types must now be `Send + Sync`.
This is a breaking change, `T: Send + !Sync` userdata types can be wrapped in a `Mutex`
or used inside a `Scope` where this restriction is lifted.
This functionality uses Luau private api to dump heap mempory in JSON format for inspection.
The new type `HeapDump` represents memory snapshot with some basic API to calculate stats.
This is a follow-up from mlua-rs/lua-src-rs#13 which verifies/tests that
mlua/lua all work when compiled for a WASI target. While this doesn't
have formal documentation yet it also codifies in CI configuration how
to build for WASI and get tests passing (notably C compiler
configuration and some misc Rust flags).
This moves some `dev-dependencies` that don't compile for
`wasm32-wasip2` to a different section of the manifest. This
additionally annotates panicking tests with `#[cfg(not(panic =
"abort"))]` to skip those tests on WASI.
This does not test either the `send` or `async` feature at this time.
Testing `send` requires threads which WASI does not yet support, and
testing `async` requires more support in Tokio which is not currently
there yet.
This option would allow detecting mixed tables (with array-like and map-like entries or several borders)
to encoding them chosing the best method (as a map or as a table).
In particular we cannot yeild across metamethod/C-call boundaries.
This behaviour matches with Lua 5.3+ yielding from hooks only at safe points.
Closes#632
When Lua is configured without memory restrictions, we use fastpath for table creation (unprotected mode).
In generally it's safe as long as we `abort()` on allocation failure.
However some Lua versions have additional restrictions on table size that we need to adhere in mlua too.
Probably Luau has the lowest limits.
Fixes#627
In Lua 5.3+ the function `lua_isinteger` returns "false" for -0.0 numbers.
In earlier Lua versions we should follow the same behavior to avoid losing the sign when converting to Integer.
Close#618
Alex Orlenko