Where is the type declaration system defined in Luau Source Code? #1190
-
|
Let's say I wanted to change the behavior of type declaration, e.g. local test: {}local test = {} :: {}Where would this be declared at? E.g. define a new type of type declaration or grammar like So I can add something like local test = {} :: {something that tells that it will be a free table}What would then even be the best way to test the changes specifically related to type declaration? 🤔 |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
|
I think it's this https://github.com/luau-lang/luau/blob/upstream/Ast/src/Lexer.cpp |
Beta Was this translation helpful? Give feedback.
-
|
This is a relatively involved question. You would have to make a change to the parser code to parse your new type annotation, which needs some degree of care to ensure that the syntax you add is unambiguous. That just adds the syntax support; it won't actually do anything (and will actually crash the type solver) without further effort. The type solver requires making a number of changes. The old solver will need changes to TypeInfer.cpp. The new solver could require a number of changes across several files depending on what this syntax is designed to do. Testing those changes is done in files in the To address the idea in your original post, you should not add a type annotation for a free table. As mentioned in #1189, free tables are an implementation detail. They're primarily used to infer a generic table or to leave room for us to convert from a table to a class later in the type solving process. They're intended to be quickly converted to another type; they are not intended to be part of a module's export surface, and with our current implementation exposing one would cause a memory safety issue. |
Beta Was this translation helpful? Give feedback.
-
|
Free tables don't sound optimal either, I'd use unsealed tables over sealed tables, but even unsealed tables get converted into sealed after requiring a Module, which doesn't make sense if your module has a field that is named |
Beta Was this translation helpful? Give feedback.
This is a relatively involved question. You would have to make a change to the parser code to parse your new type annotation, which needs some degree of care to ensure that the syntax you add is unambiguous. That just adds the syntax support; it won't actually do anything (and will actually crash the type solver) without further effort.
The type solver requires making a number of changes. The old solver will need changes to TypeInfer.cpp. The new solver could require a number of changes across several files depending on what this syntax is designed to do.
Testing those changes is done in files in the
tests/directory.To address the idea in your original post, you should not add a type an…