Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: update unwind_tables for latest Zig #127

Closed
wants to merge 20 commits into from
Closed

Conversation

robbielyman
Copy link
Collaborator

the type of unwind_tables changed from ?bool to enum { none, sync, @"async" }; this PR changes luajit.zig to accommodate this change.

NB – i'm not familiar with libunwind and it is not clear to me whether sync or @"async" is the correct choice! I went with sync because the Zig compiler appears to fall back to that if it needs to.

Renames all errors to be prefixed with Lua as a sort of namespacing.

error.Memory is renamed to error.OutOfMemory to match the Zig errors

Closes #16
In preparation for #106, remove these functions that are not needed.
These functions conflict with the original intention of using a Zig
Allocator to handle all the memory allocation. It should not be
necessary to swap out an allocator function or inspect the allocator
function during runtime, and that would more than likely lead to bugs.

Closes #51
The allocator is not conventional in Zig code. This wasn't causing any
issues from what I can see, but it is still good to follow the
conventions.

The solution is to store a copy of the allocator in an *Allocator stored
on the heap. This is done in the Lua.init function. That allocator is
then retrieved during Lua.deinit by calling c.lua_getallocf to get the
allocator pointer stored on the heap.

Closes #106
Any ziglua.wrap supported function that has a *Lua parameter now allows
using error unions in the return type. Any Zig errors that are returned
will be raised as a Lua error.

Closes #47
This is already covered by Lua.deinit()
Still a work in progress

See #25
This is better than an out parameter
Refactors call, callCont, protectedCall, and protectedCallCont to accept
a struct of arguments rather than parameters. This improves
documentation at the call site.
@robbielyman robbielyman closed this Mar 6, 2025
@robbielyman robbielyman deleted the update-to-latest branch March 6, 2025 15:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants