LuaLS / LuaLS/lua-language-server
more emmylua enhancements
Đang mở
Chưa có ai nhận issue này.
enhancement
- Ngôn ngữ chính
- Lua
- Star
- 4.4k
- Fork
- 442
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Mô tả
(it's okay to close this if they're not possible, just wondering if they're possible)
- (if possible) support for nice highlighting for
ffi.cdef([[]]), not just the version without parens- (edit: i don't think it's reasonable, seems like it's the builtin highlighting that's doing this)
- erroring on
string + anything,table + anything,anything + string,anything + table - adding enum members to autocomplete
- taking into account the implicit return at the end of a function, into the signature:
-- inferred: nil, string (incorrect)
local function bad()
if 0 > 0 then return nil, "an error" end
end
-- inferred: nil, string | nil (correct), however:
local function bad()
if 0 > 0 then return nil, "an error" end
return -- marked as a redundant return
end
- keeping warning about missing return value for these cases:
- i realize this may be disabled because the user might still be writing the function, but i'd prefer it if it always has the warning, so i can be sure that 0 warnings === it's definitely going to run correctly. so maybe it could be an option
function foo()
end
function foo() end
- retaining flow typing for declarations with initializers:
--- @type foo | nil
local x
x = { foo = 1 }
x.foo -- works
--- @type foo | nil
local x = { foo = 1 }
x.foo -- need check nil (| nil overrides flow typing from the initializer)
- better typechecking in general? examples:
--- @class foo
--- @class bar
--- @param foo foo
local function fn(foo)
end
--- @param foos foo[]
local function fn2(foos)
end
local f --- @type foo
local b --- @type bar
fn(f) -- ok
fn(b) -- error
fn({ f }) -- ok (incorrect)
fn2({ f }) -- ok
fn2(f) -- ok (incorrect)
fn2(b) -- ok (incorrect)
@classsuppresses "global variable in lowercase initial" warning:
--- @class foo
function f()
end
- disallowing assigning decimal literals to integer variables, and numbers to different numbers (it already does this between string/number/table/string literals/integer literals etc.):
- i guess the real issue is not having decimal literal types?
--- @type integer
local foo = 1.1
--- @type 10
local foo = 1.1 -- this should error at least
- disallowing comparisons between incompatible types
- i understand this may be hard, but imo it's useful even in a simple form - e.g. checking if unions have no members that are compatible with each other (somehow...?)
- in my specific case it's just between
string|string[]andnumberso even just handling it only for primitives and arrays would be quite helpful
- in my specific case it's just between
- i understand this may be hard, but imo it's useful even in a simple form - e.g. checking if unions have no members that are compatible with each other (somehow...?)
- recursive types (not necessarily generic) - in my case i have an
@alias tree_node table<string, tree_leaf | tree_node>- i've seen #1161 which seems to imply that recursive generics are too complex - not sure if this applies to normal types
- allow
@type my_function_aliasas an alternative to@param+@return- this may be useful for e.g. request handlers for a web framework
fun(req: request, res: response): nil - it seems to kind of work for
local foo = functionandlocal function foo. doesn't seem to work forreturn function- by "kind of work" - the type of the variable seems to be fine, but it doesn't copy the argument types to the function definition:
- this may be useful for e.g. request handlers for a web framework
--- @type fun(a: integer, b: integer): nil
local function foo(a, b)
-- ^ ^ a: any, b: any
end
- check for missing properties - for example this currently shows no warnings:
--- @type { a: number, b: string }
local foo = {}
- i understand that this may be difficult to do in some cases, but like above, i think even partial support (comparing type to shape at the end of scope, or type at
return, etc) would go a long way
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Hướng nghiên cứu
Bắt đầu bằng cách tách các yêu cầu chưa được kiểm tra khỏi các mục đã hoàn thành trong issue này, sau đó tái hiện các ví dụ Lua về suy luận giá trị trả về, tính tương thích kiểu, các kiểu đệ quy, phép so sánh và các thuộc tính bị thiếu. Chọn một hành vi có phạm vi hẹp và xác định việc hoàn thành dựa trên cảnh báo hoặc kết quả suy luận tương ứng được hiển thị trong ví dụ; issue không nêu tên tệp, bài kiểm thử hay một điểm vào cụ thể.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- lua
- Lĩnh vực
- tooling
- Loại issue
- Tính năng
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức độ hoạt động
- Đình trệ
- Độ rõ ràng
- Cần làm rõ
- Mức phù hợp với người mới
- 15/100