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

Make type packs less strict. #767

Closed
ghost opened this issue Dec 2, 2022 · 5 comments · Fixed by #899
Closed

Make type packs less strict. #767

ghost opened this issue Dec 2, 2022 · 5 comments · Fixed by #899
Labels
bug Something isn't working prioritized We plan to do this

Comments

@ghost
Copy link

ghost commented Dec 2, 2022

There are many built-in functions in Lua that take or return a variadic number of arguments.

For example, lets take unpack. This has the type of ({[any]: any}) -> ...any. The problem with these functions is when we try to work with type packs ontop of them

local t = {t()}
return unpack(t) --Failed to unify generic and variadic type packs

It would be nicer if ...any was permitted as a typepack unification if we're in non-strict mode

@ghost ghost added the enhancement New feature or request label Dec 2, 2022
@vegorov-rbx
Copy link
Collaborator

What is t()?

@ghost
Copy link
Author

ghost commented Dec 2, 2022

t() is a function that represents a return typepack, I guess the best way to put it for now is <T...>() -> T...

@zeux
Copy link
Collaborator

zeux commented Mar 14, 2023

Could you provide a complete example that generates the error mentioned above?

@ghost
Copy link
Author

ghost commented Mar 15, 2023

The issue is mainly when you feed a typepack into a function that takes an any

local function somethingThatsAny(...: any)
	print(...)
end

local function x<T...>(...: T...)
	somethingThatsAny(...) -- Failed to unify variadic type packs
end

I'm ok with T... throwing for more constrained varadics, but in the context where it's any/...any it should be allowed

@zeux zeux added bug Something isn't working and removed enhancement New feature or request labels Mar 15, 2023
@zeux
Copy link
Collaborator

zeux commented Mar 15, 2023

Thanks! This is helpful and actionable. I don't think we intended for this to happen.

@andyfriesen andyfriesen added the prioritized We plan to do this label Apr 6, 2023
vegorov-rbx added a commit that referenced this issue Apr 14, 2023
* Fixed exported types not being suggested in autocomplete
* `T...` is now convertible to `...any` (Fixes
#767)
* Fixed issue with `T?` not being convertible to `T | T` or `T?`
(sometimes when internal pointer identity is different)
* Fixed potential crash in missing table key error suggestion to use a
similar existing key
* `lua_topointer` now returns a pointer for strings

C++ API Changes:
* `prepareModuleScope` callback has moved from TypeChecker to Frontend
* For LSPs, AstQuery functions (and `isWithinComment`) can be used
without full Frontend data

A lot of changes in our two experimental components as well.

In our work on the new type-solver, the following issues were fixed:
* Fixed table union and intersection indexing
* Correct custom type environments are now used
* Fixed issue with values of `free & number` type not accepted in
numeric operations

And these are the changes in native code generation (JIT):
* arm64 lowering is almost complete with support for 99% of IR commands
and all fastcalls
* Fixed x64 assembly encoding for extended byte registers
* More external x64 calls are aware of register allocator
* `math.min`/`math.max` with more than 2 arguments are now lowered to IR
as well
* Fixed correctness issues with `math` library calls with multiple
results in variadic context and with x64 register conflicts
* x64 register allocator learnt to restore values from VM memory instead
of always using stack spills
* x64 exception unwind information now supports multiple functions and
fixes function start offset in Dwarf2 info
RomanKhafizianov added a commit to RomanKhafizianov/luau that referenced this issue Nov 27, 2023
* Fixed exported types not being suggested in autocomplete
* `T...` is now convertible to `...any` (Fixes
luau-lang/luau#767)
* Fixed issue with `T?` not being convertible to `T | T` or `T?`
(sometimes when internal pointer identity is different)
* Fixed potential crash in missing table key error suggestion to use a
similar existing key
* `lua_topointer` now returns a pointer for strings

C++ API Changes:
* `prepareModuleScope` callback has moved from TypeChecker to Frontend
* For LSPs, AstQuery functions (and `isWithinComment`) can be used
without full Frontend data

A lot of changes in our two experimental components as well.

In our work on the new type-solver, the following issues were fixed:
* Fixed table union and intersection indexing
* Correct custom type environments are now used
* Fixed issue with values of `free & number` type not accepted in
numeric operations

And these are the changes in native code generation (JIT):
* arm64 lowering is almost complete with support for 99% of IR commands
and all fastcalls
* Fixed x64 assembly encoding for extended byte registers
* More external x64 calls are aware of register allocator
* `math.min`/`math.max` with more than 2 arguments are now lowered to IR
as well
* Fixed correctness issues with `math` library calls with multiple
results in variadic context and with x64 register conflicts
* x64 register allocator learnt to restore values from VM memory instead
of always using stack spills
* x64 exception unwind information now supports multiple functions and
fixes function start offset in Dwarf2 info
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working prioritized We plan to do this
Development

Successfully merging a pull request may close this issue.

3 participants