Lua Language Server Fails to Infer Type When Passing Multiple Return Values to Generic Function

[Isrothy]

How are you using the lua-language-server?

NeoVim

Which OS are you using?

MacOS

What is the issue affecting?

Type Checking

Expected Behaviour

---@return integer
---@return string
local f = function()
	return 1, "a"
end

---@generic T
---@generic U
---@param t T
---@param u U
---@return U
local g = function(t, u)
	return u
end

local x = g(f())

When the function g is called with the multiple return values of f, the Lua Language Server should infer the type of x based on the second return value of f (string), corresponding to the second generic type parameter (U) in g.

Actual Behaviour

The Lua Language Server fails to infer the type of x. Instead, the type is left unknown.

Reproduction steps

1. Write the following Lua code in an editor with the Lua Language Server enabled:

---@return integer
---@return string
local f = function()
	return 1, "a"
end

---@generic T
---@generic U
---@param t T
---@param u U
---@return U
local g = function(t, u)
	return u
end

local x = g(f())

2. Observe the type inference for x.
3. Note that the type of x is not inferred as string as expected.

Additional Notes

No response

Log File

No response

[litoj]

I have a similar problem. In my case, when I wrap the return values in a table that I'm passing to a function it says that I am passing it only a table filled on the first index.

However, when I save it to a variable first, it still thinks there is only the first index, but for some reason passes the variable to the function with no error.

function mr() return 1,2,3,4 end
local x = {mr} -- still infers {[1]=number}
-- says values [2],[3],[4] are missing
vim.treesitter.get_parser(0):node_for_range({mr()})
-- doesn't say anything and correctly infers the called function's return type
vim.treesitter.get_parser(0):node_for_range(x)

This ends up being very inconvenient, because even with the diagnostic ignored it still believes there is no match for the parameters therefore the return type of function that received the table is unknown. And that breaks the type inference and completion for everything using that and so on.