news-2019-11-11-luau-recap-november-2019.md
November 11, 2019
A few months ago, we’ve released our new Lua implementation, Luau (Faster Lua VM Released) and made it the default for most platforms and configurations. Since then we’ve shipped many smaller changes that improved performance and expanded the usability of the VM. Many of them have been noted in release notes but some haven’t, so here’s a recap of everything that has happened in the Lua land since September!
When we launched the new VM, we did it without the full debugger support. The reason for this is that the new VM is substantially different and the old implementation of the debugger (that relied on line hooks) just doesn’t work.
We had to rebuild the low level implementation of the debugger from scratch - this is a tricky problem and it took time! We are excited to share a beta preview of this with you today.
To use this, simply make sure that you’re enrolled in the new Lua VM beta:
After this you can use the debugger as usual. If you see any bugs, please feel free to report them!
pairs/ipairs now works for localized versions of these globals as well, as well as next, table expressionsFastcall requires the function call to be present in source as a global or localized global access (e.g. either math.max(x, 1) or max(x, 1) where local max = math.max). This can be substantially faster than normal calls, e.g. this makes SHA256 benchmark ~1.7x faster. We are currently optimizing calls to bit32, math libraries and additionally assert and type. Also, just like other global-based optimizations, this one is disabled if you use getfenv/setfenv.
We’ve implemented most library features available in later versions of upstream Lua, including:
table.pack and table.unpack from Lua 5.2 (the latter is same as global unpack, the former helps by storing the true argument count in .n field)table.move from Lua 5.3 (useful for copying data between arrays)coroutine.isyieldable from Lua 5.3math.log now accepts a second optional argument (as seen in Lua 5.2) for the logarithm baseWe’ve also introduced two new functions in the table library:
table.create(count, value) can create an array-like table quicklytable.find(table, value [, init]) can quickly find the numeric index of the element in the tableAutocomplete support for table.create/table.find will ship next week
We’ve started taking a look at improving the Lua syntax. To that end, we’ve incorporated a few changes from later versions of Lua into the literal syntax:
\z (skip whitespace), \x (hexadecimal byte) and \u (Unicode codepoint) escape sequencesand implemented a few extra changes:
0b0101011_000_000Note that the literal extensions aren’t currently supported in syntax highlighter in Studio but this will be amended soon.
Error messages are slowly getting a bit of love. We’ve improved some runtime errors to be nicer, in particular:
We’ve also improved some parse errors to look nicer by providing extra context - for example, if you forget parentheses after function name in a function declaration, we will now say Expected '(' when parsing function, got 'local'.
We are looking into some reports of misplaced line numbers on errors in multi-line expressions but this will only ship later.
There are always a few corner cases that we miss - a new Lua implementation is by necessity subtly different in a few places. Our goal is to find and correct as many of these issues as possible. In particular, we’ve:
-0)getfenv(0) wouldn’t properly deoptimize access to builtin globalsNaNs didn’t behave properly (0/0==1)Also, the upvalue limit in the new VM has been raised to 200 from 60; the limit in Lua 5.2 is 255 but we decided for now to match the local limit.
Along with the compiler and virtual machine, we’ve implemented a new linting framework on top of Luau which is similar to our old script analysis code but is richer. In particular, we support a few more checks that are enabled by default:
Instance.new/GetService/IsA calls, is now also emitted when the result of type/typeof is compared to a string literalfor i=9,1 or for i=#t,1 as well as cases where numeric for loop doesn’t reach the stated target (for i=1,4.5)local name do ... name = value ... end)We also have implemented a few more warnings for common style/correctness issues but they aren’t enabled yet - we’re looking into ways for us to enable them without too much user impact:
There’s a fair bit of performance improvements that we haven’t gotten to yet that are on the roadmap - this includes general VM optimizations (faster function calls, faster conditional checks, faster error handling including pcall) and some library optimizations (in particular, Vector3 math performance improvements). And we’re starting to look into some exciting ways for us to make performance even better in the future.
Also we’re still working on the type system! It’s starting to take shape and we should have something ready for you by the end of the year, but you’ll learn about it in a separate post :smiley:
As always don’t hesitate to reach out if you have any issues or have any suggestions for improvements.