-
Notifications
You must be signed in to change notification settings - Fork 392
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Track the location of FunctionType declarations #802
Labels
enhancement
New feature or request
Comments
andyfriesen
pushed a commit
that referenced
this issue
Nov 2, 2023
For table type aliases, records the location of the property in the alias declaration. This is an alternate solution to the particular case noted in #802. Instead of tracking the type alias definition for FTVs, it tracks it for the encompassing property instead. Note that we still don't have positions in the following case: ``` type Func = () -> () ``` Closes #802 (Although not completely...)
alexmccord
added a commit
that referenced
this issue
Nov 10, 2023
# What's changed? - Record the location of properties for table types (closes #802) - Implement stricter UTF-8 validations as per the RFC (luau-lang/rfcs#1) - Implement `buffer` as a new type in both the old and new solvers. - Changed errors produced by some `buffer` builtins to be a bit more generic to avoid platform-dependent error messages. - Fixed a bug where `Unifier` would copy some persistent types, tripping some internal assertions. - Type checking rules on relational operators is now a little bit more lax. - Improve dead code elimination for some `if` statements with complex always-false conditions ## New type solver - Dataflow analysis now generates phi nodes on exit of branches. - Dataflow analysis avoids producing a new definition for locals or properties that are not owned by that loop. - If a function parameter has been constrained to `never`, report errors at all uses of that parameter within that function. - Switch to using the new `Luau::Set` to replace `std::unordered_set` to alleviate some poor allocation characteristics which was negatively affecting overall performance. - Subtyping can now report many failing reasons instead of just the first one that we happened to find during the test. - Subtyping now also report reasons for type pack mismatches. - When visiting `if` statements or expressions, the resulting context are the common terms in both branches. ## Native codegen - Implement support for `buffer` builtins to its IR for x64 and A64. - Optimized `table.insert` by not inserting a table barrier if it is fastcalled with a constant. ## Internal Contributors Co-authored-by: Aaron Weiss <[email protected]> Co-authored-by: Alexander McCord <[email protected]> Co-authored-by: Andy Friesen <[email protected]> Co-authored-by: Arseny Kapoulkine <[email protected]> Co-authored-by: Aviral Goel <[email protected]> Co-authored-by: Lily Brown <[email protected]> Co-authored-by: Vyacheslav Egorov <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Given the following type definition:
We can retrieve the
FunctionType
corresponding to themap
prop.On the FTV, the
definition
value is null, which makes sense given that its not the actual definition of the function.Unfortunately, we therefore have no way to get the location of the FTV (i.e. Line 2, Col 7)
It would be useful to be able to get the location here. Would it make sense to have a "declaration" field as well? Or should definition be populated
The text was updated successfully, but these errors were encountered: