Age | Commit message (Collapse) | Author |
|
|
|
|
|
with `n` up to 65535 for all Lua versions.
|
|
|
|
Using rustdoc links (see RFC https://github.com/rust-lang/rfcs/pull/1946)
|
|
|
|
|
|
|
|
|
|
This reverts commit 84fe5f7f761e5a9669ae00df3f6e48ef2814272c.
|
|
|
|
Attach only one upvalue to callbacks rather than two.
This leads to less lookup to Lua registry.
|
|
|
|
This can happen if we unable to push metatable with `__gc` metamethod after pushing userdata.
In this case Lua will never execute drop.
Instead, we will push metatable first and then userdata.
|
|
I think this experiment is unsuccessful and does not work well in a module mode
with dynamic symbols resolution and mixing between different mlua instances.
Overall the Rust bug has been fixed and we can wait for the "C-unwind" feature become stable.
|
|
|
|
|
|
Other minor code and documentation updates
|
|
|
|
|
|
|
|
|
|
Motivation behind this change is upcoming breaking change in Rust
compiler v1.52.0 to prevent unwinding across FFI boundaries.
https://github.com/rust-lang/rust/pull/76570
The new functionality requires nightly compiler to declare FFI
functions as "C-unwind".
The fundamental solution is to use C shim to wrap "e" and "m"
Lua functions in pcall.
Additionally define Rust calling convention to trigger lua_error
on Rust behalf.
|
|
|
|
|
|
Provide safe access to UserData metatable and allow to define custom metamethods..
|
|
This reverts commit 7332c6a.
Non-static userdata is a special case and can cause segfault if try to serialize it.
Now it should be safe, plus I added non-static userdata destructor to generate better error messages
in case of accessing destructed userdata.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Squashed commit of the async branch.
|
|
|
|
|
|
|
|
|
|
|
|
avoids clashing with the previous method name to avoid confusion
|
|
|
|
Tried to explain the rationale for safety around callbacks in Lua and Scope a
bit better, because every time I don't look at this for a while I forget my
reasoning. I'm not always so great at using the right terminology, so to
whoever reads this, if I got this wrong please tell me.
|
|
Uses the same UserData trait, and should at least in theory support everything
that 'static UserData does, except that any functions added that rely on
AnyUserData are pretty much useless.
Probably pretty slow and I'm not sure how to make it dramatically faster, which
is a shame because generally when you need non'-static userdata you might be
creating it kind of a lot (if it was long-lived, it would probably be 'static).
Haven't added tests yet, will do that next.
|
|
Callbacks should not be able to capture their arguments and hold onto them,
because the `&Lua` used in previous calls will not remain valid across calls.
One could imagine an API where the specific `&Lua` is simply stored inside the
`Scope` itself, but this is harder to do, and would (badly) encourage storing
references inside Lua userdata.
Ideally, the only way it should be possible to store Lua handles inside Lua
itself is through usafety or the `rental` crate or other self-borrowing
techniques to make references into 'static types. If at all possible this
roadblock should stay, because reference types inside userdata are almost always
going to lead to a a memory leak, and if you accept the risks you should just
use `RegistryKey` with its manual removal.
|
|
The documentation describing it being a logic bug to access "outer" callback
handles when inside an "inner" callback is inaccurate, that was only true when
using an older design for handle values.
Also, there is no reason to have a separate 'callback lifetime, because 'scope
is already invariant and just using 'scope seems equivalent.
|
|
Also includes other fixes for compiletest_rs failures, and a small reorg of tests
|
|
|
|
checking functions
|
|
Since we now optionally use stack spaces for handle values, we have to be
mindful of whether our stack handle points to the stack in an outer level of
Lua "stack protection". We now keep track of the "recursion level" of Lua
instances, and do not allow ref manipulation on "outer" Lua instances until the
inner callback has returned. Also, update the documentation to reflect the
additional panic behavior.
|