LuaLS / LuaLS/lua-language-server
Generic type inference breaks for class-style tables with indexed fields (---@class list<T>: { [integer]: T })
Open
Nobody has claimed this yet.
- Dominant language
- Lua
- Stars
- 4.4k
- Forks
- 442
- PR merge metrics
- No merged PRs in 30d
Description
How are you using the lua-language-server?
Visual Studio Code Extension (sumneko.lua)
Which OS are you using?
Windows
What is the issue affecting?
Type Checking
Expected Behaviour
---@type string[]
local testA = { }
local testB = { 1, 2, 3 }
local testAA = List(testA)
local testBB = List(testB)
local vAA1 = testAA[1] -- expected: string
local vBB1 = testBB[1] -- expected: integer
local vAA2 = testAA:at(1) -- expected: string
local vBB2 = testBB:at(1) -- expected: integer
---@type list<number>
local testCC = List {}
-- newList -> expected: list<number>
local newList = testCC:whereList(function(a) return a == 0 end)
-- front -> expected: number
local front = newList:front()
Actual Behaviour
---@type string[]
local testA = { }
local testB = { 1, 2, 3 }
local testAA = List(testA)
local testBB = List(testB)
local vAA1 = testAA[1] -- actual: string|<T>
local vBB1 = testBB[1] -- actual: string|<T>
local vAA2 = testAA:at(1) -- actual: unknown
local vBB2 = testBB:at(1) -- actual: unknown
---@type list<number>
local testCC = List {}
-- newList -> actual: list<<T>>
local newList = testCC:whereList(function(a) return a == 0 end)
-- front -> actual: unknown
local front = newList:front()
Reproduction steps
---@meta
---@generic T
---@param t T[]
---@return list<T>
function List(t)
return listlib:new(t);
end
---@class list<T>: { [integer] : T }
listlib = {}
---@generic T
---@param t T[]
---@return list<T>
function listlib:new(t) end
---@generic T
---@param self list<T>
---@param index integer
---@return T
function listlib:at(index) end
---@generic T
---@param self list<T>
---@return T
function listlib:front() end
---@generic T
---@param self list<T>
---@param predicate fun(a: T): boolean
---@return list<T>
function listlib:whereList(predicate) end
---@type string[]
local testA = { }
local testB = { 1, 2, 3 }
local testAA = List(testA)
local testBB = List(testB)
local vAA1 = testAA[1] -- expected: string, actual: string|<T>
local vBB1 = testBB[1] -- expected: integer, actual: string|<T>
local vAA2 = testAA:at(1) -- expected: string, actual: unknown
local vBB2 = testBB:at(1) -- expected: integer, actual: unknown
---@type list<number>
local testCC = List {}
-- newList -> expected: list<number>, actual: list<<T>>
-- front -> expected: number ,actual: unknown
local newList = testCC:whereList(function(a) return a == 0 end)
local front = newList:front()
Additional Notes
No response
Log File
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the minimal Lua example in the Visual Studio Code extension, starting with the generic List/listlib declarations and the class-style list annotation. Trace type inference for indexed access, at, whereList, and front. Done means inferred types match the expected string, integer, and number results instead of unknown or unresolved generic types.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- lua
- Domain
- devtools
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100