An IDE for statically typed Lua development.
Derived from EmmyLua.
- Editor Features
- Installation
- Static Analysis Features
- Demo Project
- EmmyDoc Block Comments
- Type casts
- Improved variance detection
- Primitive literal types
- Generic parameter type usage within function bodies
- Binding of EmmyDoc to lambdas in assignments
- Table type checking improvements
- Generic classes
- Support for generic params referencing generic params
- Generic inference fixes
- Type errors are now errors by default
- Generic parameter use within a class
- "No such member" inspection
selfis a real type- Type checking of immediately assigned variable declarations
- Fixed a bug where the type inference cache was being used in the presence of an index
- Added support for
@shape - Generic Aliases
- Improved vararg syntax
- Variadic return values
- Standard library type improvements
- Support for indexed fields
- Partially typed functions
- Callable types
- Strongly typed tuples
- Type lists
@nottype casts@typeannotations on return statements- Recursive alias resolution
- Casting to/from variadic type lists
- Support for optional parameters
- Building from Source
- Installation from Source
- Developed By
- Sponsors
The latest release is available for download within IntelliJ or from the Jetbrains Plugin website.
Luanalysis is derived from EmmyLua and supports all the basic editing and refactoring functionality provided by EmmyLua.
Beyond basic Lua editing capabilities, Luanalysis supports a significant amount of additional functionality necessary to statically type advanced codebases.
*Note*: Features are roughly listed in the order they were implemented, by no means order of importance.
A great way to see what’s possible in terms of static typing is to checkout the Luanalysis demo project.
In addition to defining new types, the @type tag can now be also used to cast the result of a Lua expression.
This is most useful with the newly added support for EmmyDoc block comments as we can easily specify inline type casts:
EmmyLua attempts to determine if a type is assignable to another type simply by checking if the former is a "subtype" of latter, however proper type variance of complex types is not implemented. For example, functions may be covariant or contravariant of other function types, depending on parameters and return value types:
EmmyLua does not report the above error.
Additionally, union variance detection has been fixed:
As above, the current release of EmmyLua does not catch this error.
i.e. Type checking now works inside function "lambdas" assigned to a variable with an EmmyDoc definition.
Various improvements, for example EmmyDoc "arrays" are now assignable to compatible table types e.g.
The current EmmyLua release will report an error here even though this is sound.
The current EmmyLua release is unable to infer generics correctly in several situations and thus reports type errors where no error exists, and also misses errors where errors should exist e.g.
By default, type safety errors are now reported as errors instead of warnings. This is made feasible by three things:
-
Many improvements in the ability to specify complex types
-
Type safety bug fixes
-
Casting
Casting in particular means that if a user is doing something the type system deems unsafe, but they know at runtime will be fine, they can just add a cast to signify this and the error will go away.
Shadowing of a generic parameter is forbidden and an error reports:
Improved type checking for self, for example self can be assigned to a variable that matches the parent type of a method.
However, that parent type cannot be assigned to self, as the class may be sub-classed (in which case self refers to a more specific type).
Current EmmyLua release will allow this invalid assignment.
When a function returns multiple values, the current EmmyLua release will infer values and put them in the cache. This is inaccurate as generic types analysis may result in the same generic parameter being resolved differently based on the value being assigned, thus the cache cannot be used in this circumstance. Presently this results in both missing errors, and additional inaccurate errors, depending on the assignment.
A shape can be defined similarly to a class, except that contravariance is determined by compatibility of the members not the inheritance hierarchy.
This is most useful when working with "structures" (e.g. JSON) rather than OOP classes.
What makes shapes particularly useful is that they support generics and inheritance (at definition time, not assignment) just like classes:
Even better, type inspections are not just reported on incompatible `table`s as whole, but rather the inspections know how to traverse table literals and provide detailed annotations of incompatibilities between two shapes e.g.
Aliases can now take generic parameters, just like a class or shape.
We now support variadic return values:
Internally, TyTuple has been replaced with TyMultipleResults to reflect the fact that this construct is not fixed size.
Additionally, multiple results are now properly handled in more locations.
Various improvements to typings of Lua built-ins taking advantage of variadic return values etc.
We can now type all properties of tables, not just string constants. Given that Luanalysis also adds support for primitive literal types we can use this a lot of different ways e.g.
Here we have regular string identifier fields, number literal fields
[1], [2] and [3] and a [boolean] field.
That last one is really powerful, because it’s not a constant, it’s a real type.
We can type custom data structures e.g.
---@class Dictionary<K, V>
---@field [K] VThis will work correctly for any K and everything will be statically type checked as you’d expect.
There’s also syntax for table types, it works for table literals and anonymous classes (i.e. tables that aren’t explicitly typed):
We now support fun types with optional parameter lists and optional return values i.e. fun: boolean and fun(arg: boolean). fun (with neither specified) also works for posterity but is functionally equivalent to the existing function type.
Partially typed functions are extremely useful for implementing callback and handler patterns.
For example, it’s quite common to have an extensible event system where each event has unique arguments, but the handler must return true to indicate the event was handled:
This is another really useful feature.
We can now properly indicate that an object is callable (i.e. is a table whose metatable has a
__call method).
This is done by using the existing @overload EmmyDoc keyword, and works similarly i.e. we can specify many overloads and type checking and completion will work as you’d expect:
Tuples can be implemented as shapes with number literal indexes:
or as aliases of table literal types:
As can be seen above, when a tuple is compatible with an array, it can be assigned to one, but not vice versa.
The @type annotation supports a list of types.
This can be used when declaring variables:
or for casting multiple results returned by an expression (e.g. function call):
A @not type cast eliminates types from a union.
It’s useful in a variety of circumstances, the most straight-forward of which is eliminating nil:
Like @type, is also supports type lists for casting multiple return values of a function, and can itself eliminate unions:
When you simply want to eliminate types from a union, it’s generally safer to use @not cast than a @type cast because a @type cast essentially disables all type checking for the assignment, where as
@not cast just excludes certain types.
Return statements now accept type annotations, which are type-safe way of typing the return value of anonymous lambdas.
Unlike a type cast, these are type-safe:
Alias types are now lazily resolved, which allows us to type recursive data structures. For example, JSON:
A functions API may return an unknown number of results. However, when calling these functions, you tend to know how many results you expect back.
A variadic return value can be cast to a concrete type list by @not
casting away nil:
One variadic type may also be cast to another:
We now support optional parameters in both short and long-form function type definitions e.g.
Importantly, optional is not short-hand for nil | type.
You cannot provide nil unless the optional parameter type itself include nil as part of a union in its type definition. This is desirable for
correctness purposes when implementing functions in Lua, say for example if the implementation makes use of
[select('#', …)](https://www.lua.org/manual/5.3/manual.html#pdf-select). However, beyond that, Lua is regularly used as a scripting language, binding Lua
function calls to implementations in other languages that have support for overloads etc. where the number and type of arguments are important.
Inspections that prevent incorrect optional parameter order have also been implemented:
Build the plugin with:
./gradlew buildFor more details about the Jetbrains Platform SDK please refer to the official documentation.
The resultant plugin .zip will end up in the directory ./build/distributions/.
To install the .zip you built, you’ll need to go to IntelliJ’s…
Preferences -> Plugins -> Settings Cog Icon -> Install Plugin from Disk...
Select the .zip, and then when prompted, restart IntelliJ.
Luanalysis by: Benjamin Dobell
EmmyLua by: @tangzx 阿唐
Contributors
Please refer to Github for a complete list of contributors.
/sponsor/avatar/0){kind=small}
/sponsor/avatar/1){kind=small}
/sponsor/avatar/2){kind=small}
/sponsor/avatar/3){kind=small}
/sponsor/avatar/4){kind=small}
/sponsor/avatar/5){kind=small}
/sponsor/avatar/0){kind=small}
/sponsor/avatar/1){kind=small}
/sponsor/avatar/2){kind=small}
/sponsor/avatar/3){kind=small}
/sponsor/avatar/4){kind=small}
/sponsor/avatar/5){kind=small}
/sponsor/avatar/6){kind=small}
/sponsor/avatar/7){kind=small}
/sponsor/avatar/8){kind=small}
/sponsor/avatar/9){kind=small}
/sponsor/avatar/10){kind=small}
/sponsor/avatar/11){kind=small}
/sponsor/avatar/12){kind=small}
/sponsor/avatar/13){kind=small}
/sponsor/avatar/14){kind=small}
/sponsor/avatar/15){kind=small}
/sponsor/avatar/16){kind=small}
/sponsor/avatar/17){kind=small}
/sponsor/avatar/18){kind=small}
/sponsor/avatar/19){kind=small}