Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
Don't allow to set hook if main_state is not available
Remove Lua 5.1 dirty hack
|
|
- In safe mode Lua would not have ability to load C code via `require` or `package.loadlib`
- Unsafe mode allows everything.
|
|
|
|
|
|
|
|
Squashed commit of the async branch.
|
|
- Make Value::type_name() public
- Update CallbackError and ExternalError Display impl
|
|
|
|
|
|
|
|
|
|
|
|
|
|
other minor refactors
|
|
|
|
|
|
|
|
There are also some other drive-by changes to fix panicking in extern "C"
functions and other edge case stack errors
|
|
Also removes some cleverness if debug_assertions was disabled, as it really
doesn't make much of a performance difference.
|
|
|
|
Now, simply remove the userdata table immediately before dropping the userdata.
This does two things, it prevents __gc from double dropping the userdata, and
after the first call to __gc, it prevents the userdata from being identified as
any particular userdata type, so it cannot be misused after being finalized.
This change thus removes the userdata invalidation error, and simplifies a lot
of userdata handling code.
It also fixes a panic bug. Because there is no predictable order for
finalizers, it is possible to run a userdata finalizer that does not resurrect
itself before a lua table finalizer that accesses that userdata, and this means
that there were several asserts that were possible to trigger in normal Lua code
in util.rs related to `WrappedError`.
Now, finalized userdata is simply a userdata with no methods, so any use of
finalized userdata becomes a normal script runtime error (though, with a
potentially confusing error message). As a future improvement, we could set
a metatable on finalized userdata that provides a better error message.
|
|
|
|
This is a pretty opinionated change, but I find documentation to be
clearer when using plain old names everybody understands immediately.
|
|
|
|
|
|
|
|
Also make sure that panic messages clearly state that they are internal errors,
so people report them as a bug. Since the only panics left are all internal
errors, just move the internal error message into the panic / assert macros.
|
|
- Update readme, changelog, cargo version number in preparation for release
- Remove panicking behavior on recursive callback calls, add additional error
variant for recursive callback errors.
|
|
|
|
|
|
|
|
CallbackError now, instead of displaying the cause description, instead prints
"callback error: <traceback>". Since the cause is already in the cause chain of
the error, this avoids repeatedly printing the cause of callback errors along
the chain, and also actually prints the callback when using Display on each
error in the chain.
|
|
|
|
|
|
|
|
Since this is `rlua::Error`, it should be clear that it refers to
Lua-related errors. Downstream crates want to define their own error
enums, which can add a prefix like "lua error:" to disambiguate.
|
|
Both are a form of syntax error, this reflects that better. No
functionality is lost, incomplete inputs are moved to a bool field of
SyntaxError.
|
|
Previously, the traceback would be printed, but not the actual error.
I've removed traceback printing completely, not sure if that's a good
idea. A `Display` impl that outputs multiple lines feels weird.
|
|
|
|
|
|
I didn't yet document *everything* there is to say (in particular, how
exactly custom Rust errors can be passed through Lua), but I've some
changes to this type in mind that I'll do next.
|
|
|
|
I am not actually sure what the best pattern is to import conflicting
standard types, but this is at least consistent.
|
|
Rename the following:
LuaNil => Nil
LuaExternalError => ExternalError
LuaExternalResult => ExternalResult
LuaCallback => Callback (internal only)
Use qualified re-exports at the top of the module.
Add a new public 'prelude' module which re-exports everything with a
non-conflicting name (Adds back the Lua prefix), and is meant to be imported
unqualified.
|
|
|
|
cc #15
Doesn't touch `LuaString` mainly because that's a *lot* of renaming work
and the code looks weird. Also I want feedback before I proceed.
|