Tags: luau-lang/lute
Tags
Use <= instead of < (visitInterpolatedString) (#345) While working with the `visitor`, I noticed that interpolated strings were not properly traversed. It appears that is bc of this condition, which will not visit the last expression in the interpolated string node's expressions table.
Add lineOffsets field to Luau parser output (#342) This PR enhances the Luau parser to expose line offset information, enabling tooling to better access precise source location mapping for nodes. **Changes Made**: Exposes the computed 'lineOffsets' field to the Luau 'ParseResult'. Modified exisitng ast test serializer tests to work with new apis. Added new test to ensure that line offsets are exposed correctly. ```luau local result = luau.parse("local x = 1\nlocal y = 2") -- result.lineOffsets = { 0, 12 } -- Line 0 starts at char 0, line 1 starts at char 12 ```
Remove luthier.py since it's been superseded entirely by the Luau imp… …lementation. (#337) We no longer need to maintain `luthier.py`, and it poses a frustrating maintenance risk right now to attempt to apply both together. It may be useful in the future to introduce an optional path in the CI to fetch everything from a tarball somewhere and then use cmake/ninja directly instead of running luthier, but we can deal with that when needed.
Pull out new Lute.CLI.lib target to simplify testing (#333) Resolves #315. This PR doesn't currently expose anything more than the old `main` function. As we begin writing tests, we can expand the API of `Lute.CLI.lib`. At a high-level, we make `Lute.CLI` a single-source target whose `main` function simply calls into the `climain.cpp`'s `cliMain` function. This function is identical to our old `main` function but can now be called by unit tests.
Add support for multi-file CLI command scripts embedded into the lute… … executable (#314) ## Summary In this PR, we add support for running command-line Luau scripts that are stored in the `cli/commands` directory. If we have `cli/commands/foo.luau` or `cli/commands/foo/init.luau`, running `lute foo` will automatically execute the contents of that script (with support for relative requires as well). ## Implementation details We create a new `CliVfs` that is optionally be embedded in `RequireVfs`. The CLI enables this, but `vm.create` does not, as it does not need a custom VFS for command-line scripts. The actual implementation of the VFS is nearly identical to `StdLibVfs`. The embedding of the CLI scripts is done using Luthier to generate source files for a new `Lute.CLI.Commands` target. This is similar to how the `@std` libraries were embedded into the `Lute.Std` target. - #138 - #205 While working on this, I noticed that `luthier.luau` was incomplete. Due to the lack of an `os.walk` API like we have in Python, `luthier.luau` doesn't correctly handle nested directories that need to be embedded. To solve this, I have added a `traverseFileTree` function that effectively accomplishes the same thing. Because of slight differences in the order files are processed by `os.walk` and `traverseFileTree`, `luthier.py` and `luthier.luau` spit out different hashes. I think this is fine. When only using one of the tools in isolation, the caching seems to work as expected.
PreviousNext