You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
__pairs annotation specifies the iterator function as taking a third argument, for the value. Lua versions 5.2 and 5.4 do not pass a third argument to the iterator function.
__ipairs annotation specifies the iterator function as taking a third argument, for the value. Lua version 5.2 does not pass a third argument to the iterator function.
__ipairs annotation specifies the generator function as returning only 2 results. Following the annotation hinting results in nil being implicitly passed as the third argument, instead of the correct index.
t = setmetatable({1,2,3}, {
__ipairs = function(t) local function iter(t, k) k = k + 1 local v = t[k]; if v then return k, v end; end; return iter, t, 0 end,
})
for k, v in ipairs(t) do
print(v)
end
(field) __ipairs: function|nil
function (t: any)
-> fun(t: any, k: any, v: any):integer|nil
2. any
function __ipairs(t: any)
-> function
2. unknown
3. integer
Annotations specify that at most 2 return value(s) are required, found 3 returned here instead.Lua Diagnostics.(redundant-return-value)
Removing the extra return value as the annotation suggests results in :
.\sample.lua:2: attempt to perform arithmetic on local 'k' (a nil value)
stack traceback:
.\source.txt:2: in function 'for iterator'
.\source.txt:5: in main chunk
[C]: in ?
Additional Notes
The example __ipairs sample is essentially what AI generated sample code looks like, so it is likely how someone would use __ipairs.
Lua 5.2 allows iteration with __ipairs to start at any point; this is useful if __ipairs is used to support non-standard ipairs iteration, such as starting from a negative index or starting at some arbitrary positive index, controlled by altering the third return value from the generator function to be a non-zero value.
Some of the __ipairs choices in the suggested annotations I made aren't technically explicitly mandated, but I feel they are in the spirit of the intended functionality; nothing stops anyone violating the implicit assumption that the keys are sequential, have numeric indexes, or they will be traversed in a given order:
t = setmetatable({a=1,b=2,c=3}, {
__ipairs = function(t) local function iter(t, k) return next(t,k) end; return iter, t, nil end,
})
for k, v in ipairs(t) do
print(k, v)
end
I kept my suggested annotation for __ipairs in line with the normal behaviors of ipairs when there is no __ipairs metamethod.
Log File
No response
The text was updated successfully, but these errors were encountered:
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?
Annotations
Expected Behaviour
lua-language-server should specify correct function signatures for __pairs and __ipairs.
lua-language-server should in particular say that the __ipairs iterator generator function has 3 return values.
Following the annotation hints for __ipairs should not result in runtime errors.
Given that generic
for k, v in pairs(t) --or ipairs(t)
for pairs and ipairs are equivilant to:I believe these are the required function signatures:
which I believe should be:
---@field __pairs (fun(t):((fun(t,k):(any,any)),any,any))|nil
---@field __ipairs (fun(t):((fun(t,k):((integer|nil),any)),any,integer))|nil
Actual Behaviour
__pairs annotation specifies the iterator function as taking a third argument, for the value. Lua versions 5.2 and 5.4 do not pass a third argument to the iterator function.
---@field __pairs (fun(t):((fun(t,k,v):any,any),any,any))|nil
__ipairs annotation specifies the iterator function as taking a third argument, for the value. Lua version 5.2 does not pass a third argument to the iterator function.
__ipairs annotation specifies the generator function as returning only 2 results. Following the annotation hinting results in nil being implicitly passed as the third argument, instead of the correct index.
---@field __ipairs (fun(t):(fun(t,k,v):(integer|nil),any))|nil
Reproduction steps
Removing the extra return value as the annotation suggests results in :
Additional Notes
The example __ipairs sample is essentially what AI generated sample code looks like, so it is likely how someone would use __ipairs.
Lua 5.2 allows iteration with __ipairs to start at any point; this is useful if __ipairs is used to support non-standard ipairs iteration, such as starting from a negative index or starting at some arbitrary positive index, controlled by altering the third return value from the generator function to be a non-zero value.
Some of the __ipairs choices in the suggested annotations I made aren't technically explicitly mandated, but I feel they are in the spirit of the intended functionality; nothing stops anyone violating the implicit assumption that the keys are sequential, have numeric indexes, or they will be traversed in a given order:
I kept my suggested annotation for __ipairs in line with the normal behaviors of ipairs when there is no __ipairs metamethod.
Log File
No response
The text was updated successfully, but these errors were encountered: