Docs/luwu documentation rebrand - #34
Merged
deviaze merged 2 commits intoAug 17, 2026
Merged
Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates repository documentation and RFC text to reflect the project’s rebrand from Luau to Luwu, including link/path updates and an RFC rename to match the new naming.
Changes:
- Rebrands core docs (README, SECURITY, CONTRIBUTING, maintainers) from Luau → Luwu and updates repository URLs accordingly.
- Rebrands multiple extra RFC documents to reference Luwu and adjusts wording in several places.
- Replaces the “Luau-managed refs” RFC with a newly named “Luwu-managed refs” RFC document.
Reviewed changes
Copilot reviewed 14 out of 14 changed files in this pull request and generated 8 comments.
Show a summary per file
| File | Description |
|---|---|
| SECURITY.md | Updates security policy wording/repo reference for Luwu. |
| README.md | Rebrands top-level project description, links, and compatibility notes to Luwu. |
| CONTRIBUTING.md | Rebrands contribution guidance and support links to Luwu/Discord. |
| MAINTAINERS.md | Updates maintainer note to reference mluau/luwu. |
| .github/ISSUE_TEMPLATE/config.yml | Updates “Questions” contact link to Discord. |
| rfcx/README.md | Rebrands RFC guidance and improves wording/clarity. |
| rfcx/thread-statechange-hook.md | Rebrands RFC prose to Luwu. |
| rfcx/none.md | Rebrands RFC prose to Luwu. |
| rfcx/function-default-arguments.md | Rebrands RFC prose to Luwu and updates examples. |
| rfcx/fat-c-closures.md | Rebrands RFC prose to Luwu and edits motivation/summary wording. |
| rfcx/external-strings.md | Rebrands RFC prose to Luwu. |
| rfcx/external-buffers.md | Rebrands RFC prose to Luwu. |
| rfcx/api-luwu-managed-refs.md | Adds newly named RFC for Luwu-managed references. |
| rfcx/api-luau-managed-refs.md | Removes the prior Luau-named RFC document. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| Luwu is commonly paired with custom async task schedulers (like `mluau/scheduler`, other async impls). To track when a thread yields, finishes or errors, schedulers currently patch the global `coroutine.resume` function with a wrapper that intercepts the call, records the result in their scheduler, and forwards the return values. | ||
|
|
||
| Ideally, scheduling would be a first class part of Luau but this is a future goal and is orthogonal to this RFC. | ||
| Ideally, scheduling would be a first class part of Luwu but this is a future goal and is orthogonal to this RFC. |
Comment on lines
+3
to
+7
| Luwu provides a safe sandbox that scripts can not escape from, short of vulnerabilities in custom C functions exposed by the host. This includes the virtual machine, builtin libraries and native code generation facilities. | ||
|
|
||
| Any source code can not result in memory safety errors or crashes during its compilation or execution. Violations of memory safety are considered vulnerabilities. | ||
|
|
||
| Note that Luau does not provide termination guarantees - some code may exhaust CPU or RAM resources on the system during compilation or execution. | ||
| Note that Luwu does not provide termination guarantees - some code may exhaust CPU or RAM resources on the system during compilation or execution. |
|
|
||
| ## Motivation | ||
|
|
||
| Luwu already has `lua_ref`, `lua_unref` and `lua_getref` as existing C APIs that merely work with the Luwu registry (honestly should be `luaL_*` at that point?). Unfortunately, this may have performance drawbacks in certain degenerate table cases (table holes, interactions w/ the length operator for tables actually being a boundary operator in Luwu, performance etc.), leading embedders like mluau to instead hijack threads (or, in some cases, handle multiple thread stacks) to prevent GC. |
| Luwu is a community-led fork intended to provide a more featureful and helpful experience for general-purpose, open-source language development. It will evolve with features, syntax, and semantics that may not align with upstream Luau. | ||
|
|
||
| For more information about this fork, how to contribute, and help us name our new language based off of Luau (but different!), please join our discord server [hina & ferris](https://discord.gg/3MJ37CFNWh). | ||
| Luwu is backwards compatible with Luau up to and including version 0.730, with possible exceptions for `export local` and Luau's unreleased integer feature as those areas are improved in Luwu. |
| ## Motivation | ||
|
|
||
| Embedders like `mluau` currently need to use userdata (w/ a metatable etc.) and upvalues for every stateful closures. This has the downside of making C functions in luau a fair bit slower, increases GC pressure as the GC has to both handle the closure itself and the userdata allocation and less ergonomic for developers (involving needing upvalues etc.). `mluau` has a ton of infrastructure here regarding internal userdata with dtors which could be dropped while also increasing overall performance in general. | ||
| Embedders like `mluau` currently need to use userdata (w/ a metatable etc.) and upvalues for every stateful closure. This has the downside of making C functions in Luwu a fair bit slower, increasing GC pressure because the GC has to handle both the closure and the userdata allocation, and making the API less ergonomic for developers. `mluau` has a significant amount of infrastructure for internal userdata with destructors that could be dropped while improving overall performance. |
Comment on lines
25
to
+27
| While effective this produces a degree of noise at the start of functions. Notably also the `or` short-circuit approach will coalesce all falsey values to the default value, rather than just `nil` values. | ||
|
|
||
| The luau type system also does not currently narrow these types correctly. For example, | ||
| The Luwu type system also does not currently narrow these types correctly. For example, |
|
|
||
|
|
||
| By introducing external buffers, we allow embeddings to wrap existing memory allocations without copying, restrict mutation from scripts if necessary, and allow the Luau garbage collector to accurately track the memory footprint of externally allocated data. | ||
| By introducing external buffers, we allow embeddings to wrap existing memory allocations without copying, restrict mutation from scripts if necessary, and allow the Luwu garbage collector to accurately track the memory footprint of externally allocated data. |
Comment on lines
+9
to
+11
| Luwu's `string` type represents immutable byte sequences. Currently, creating a string in Luwu requires copying the bytes from the host application into a VM-managed allocation. In embedding scenarios, it is common for the host to already possess large strings (such as errors w/ stack traces, data from a JSON file etc.). | ||
|
|
||
| While external buffers do exist in Luau now, buffers cannot be manipulated by the `string` library (and other string-related operations/infrastructure) nor can they easily be used as table keys etc. Furthermore, it is expected/idiomatic for certain things in Luau to be a `string` and not a `buffer` (error tracebacks, strings in a json etc.). | ||
| While external buffers do exist in Luwu now, buffers cannot be manipulated by the `string` library (and other string-related operations/infrastructure) nor can they easily be used as table keys etc. Furthermore, it is expected/idiomatic for certain things in Luwu to be a `string` and not a `buffer` (error tracebacks, strings in a json etc.). |
deviaze
approved these changes
Aug 17, 2026
deviaze
left a comment
deviaze
left a comment
Contributor
There was a problem hiding this comment.
Overall good, we can fix some wording in post. Thanks!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.