Union table|class doesn't accept a generic table and only accepts a class instance (causing false missing-fields diagnostic)

[b-stage]

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, Diagnostics/Syntax Checking

Expected Behaviour

When a function is declared as accepting both table and a custom class type, it should accept getting passed a generic table.

Actual Behaviour

LLS insists on a table matching the class being passed (with all the fields set) and reports the missing-fields diagnostic when passing a generic table.

Reproduction steps

LLS definition file contains the following:

---@meta

---@class TestClass
---@field TestField number A test field in test class
TestClass = {}

-- TestFunction1
---@param generic_table_or_testclass_instance table|TestClass
function TestFunction1(generic_table_or_testclass_instance) end

-- TestFunction2
---@param generic_table table
---@param testclass_instance TestClass
---@overload fun(generic_table: table)
---@overload fun(testclass_instance: TestClass)
function TestFunction2(generic_table, testclass_instance) end

-- TestFunction3
---@param generic_table table
function TestFunction3(generic_table) end

-- TestFunction3
---@param testclass_instance TestClass
function TestFunction3(testclass_instance) end

And then a lua code file contains a call to either test function like

TestFunction1({1,2,3})
TestFunction2({1,2,3})
TestFunction3({1,2,3})

LLS reports Missing required fields in type ``TestClass``: ``TestField`` Lua Diagnostics.(missing-fields) for all 3 calls. Instead it should accept the table as input parameter for the 3 functions.

Additional Notes

No response

Log File

No response

[MillhioreBT]

Just make the class fields optional

---@class TestClass
---@field TestField number? A test field in test class
TestClass = {}

[b-stage]

Just make the class fields optional

Thanks for the suggestion! That was the first workaround I tried, but it gives off the wrong impression as real instances of the class always have the fields. It also makes it possible to pass a generic table to a function that only accepts the class.

So for a workaround for now I did this:

---Define a custom class for generic tables (workaround for LLS bug https://github.com/LuaLS/lua-language-server/issues/2606)
---@class any_table
any_table = {}

---@class TestClass
---@field TestField number A test field in test class
TestClass = {}

-- TestFunction1
---@param generic_table_or_testclass_instance any_table|TestClass
function TestFunction1(generic_table_or_testclass_instance) end

With this LLS is smart enough to allow both while keeping the strictness on functions that only accept a class. For functions that only accept a table I keep using the regular table, I only use any_table for overloaded function.

But I still think LLS should be fixed to make it work without the fake table class :-)

[MillhioreBT]

Yes, it is a shame that there are too many specific use cases, I have also come across some things that I would like to do and it is not possible, I just accept it and hope that in the future, After the famous Rework that they will do to LLS we should be able to cover all the problems and even be able to create solutions in itself with dynamic annotations or that execute lua code