Skip to content
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

Closed
JohnnyMorganz opened this issue Jan 11, 2023 · 0 comments · Fixed by #1046 or #1097
Closed

Track the location of FunctionType declarations #802

JohnnyMorganz opened this issue Jan 11, 2023 · 0 comments · Fixed by #1046 or #1097
Labels
enhancement New feature or request

Comments

@JohnnyMorganz
Copy link
Contributor

Given the following type definition:

export type Foo = {
  --- Maps a value
  map: () -> any,
}

We can retrieve the FunctionType corresponding to the map 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

@JohnnyMorganz JohnnyMorganz added the enhancement New feature or request label Jan 11, 2023
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
Labels
enhancement New feature or request
1 participant