Override is prevented from linter

[jakitliang]

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?

Diagnostics/Syntax Checking

Expected Behaviour

local a = {}
a.__index = a
function a:m1()
end

-- b inherit from a
local b = setmetatable({}, a)
-- override m2()
function b:m2() --- no warning generated
end

Actual Behaviour

local a = {}
a.__index = a
function a:m1()
end

-- b inherit from a
local b = setmetatable({}, a)
-- override m2()
function b:m2() --- duplicate field `m`
end

Reproduction steps

1. Just copy the code and lint them

Additional Notes

Inheritance and override methods is prevent by LuaLS linter.

Override is a common and basic concept. But LuaLS seems can't recognize it but provide warnings.

In the case, m2 is not a duplicate field, but just shadowing or overriding.

Log File

No response

[tomlau10]

You have to use @class to let luals know it is inheritance

---@class a
local a = {}
a.__index = a
function a:m()
end

-- b inherit from a
---@class b: a
local b = setmetatable({}, a)
function b:m() --> no more warning
end

But I think you will disagree with this 🤦‍♂️ according to your previous reply here: #3035 (comment)

[jakitliang]

You have to use @class to let luals know it is inheritance

---@class a
local a = {}
a.__index = a
function a:m()
end

-- b inherit from a
---@class b: a
local b = setmetatable({}, a)
function b:m() --> no more warning
end

But I think you will disagree with this 🤦‍♂️ according to your previous reply here: #3035 (comment)

We code for Lua, not for LuaLS style.

Why strongly force us marking --- @class on the top?

LuaLS detect it duplicate field since it have ability to recognize the table and also its inheritance.

It is actually a bug instead of telling me how it works for.

And this thing have exhaustively talked in a channel for 6 hours.

Many people had known what I stand for.

[jakitliang]

The reason why I stand for Linter Should Work According to Language Specifications is that:

[tomlau10]

Ah~ with the image related to your previous discussion context that you posted, now I understand what you want to express.

In your example here, a / b is just a normal variable.
Nothing will be instantiated from them => they are not class (in concept).

I've read some of luals's codebase before, and seems currently setmetatable() will just merge the 2 values => gives a merged type

• In this case setmetatable({}, a) => a table type which already has a m field
• but it's just in the __index table, and should not warn users when they try to shadow with b:m() definition

Now I agree that this is a bug, or I should say something to be improved by luals 👍
=> the current duplicate-set-field would produce false-postive results.
Though they can be workarounded by using @class, that's not the proper way to solve the issue (In the use case of this example)
Although I don't know how the improvement can be implemented, but that's not my concern 😂

---

The reason why I stand for Linter Should Work According to Language Specifications is that:

However I am not sure if I understand this statement 😕
Any valid lua code by itself, conform to the Language Specifications.
For example

• trailing spaces
• empty if branch
• code cannot reach
• ... more and more

Then are you saying that all kind of these check should be disabled by default 😳 ?

---

Following is a bit off topic, but there are a few points I want to add:

• In my team we also set up luacheck which is another linter that do file-based analysis
• it also has duplicate-index check

local t = { --> unused variable 't'
    a = function () end,  --> value assigned to field 'a' is overwritten on line 3 before use
    a = 2,
}
function t:a() end --> no warning

• clearly when writing table literal, defining the same field twice is probably a mistake => warning
  Maybe this is what you want to express: if linter want to enforcing rules, it should work perfect and correct as it is ? 🤔

PS:
Please be reminded again that I am just a user / contributor of luals, I am not maintainer.
All the above are my own opinions which cannot represent maintainers' view.
I don't want to give you a feeling that luals community doesn't welcome new issues 🙏
I tried to give my reasoning as detailed/logical as I can when I reply you. 😄

[jakitliang]

Ah~ with the image related to your previous discussion context that you posted, now I understand what you want to express.

In your example here, a / b is just a normal variable. Nothing will be instantiated from them => they are not class (in concept).

I've read some of luals's codebase before, and seems currently setmetatable() will just merge the 2 values => gives a merged type

• In this case setmetatable({}, a) => a table type which already has a m field
• but it's just in the __index table, and should not warn users when they try to shadow with b:m() definition

Now I agree that this is a bug, or I should say something to be improved by luals 👍 => the current duplicate-set-field would produce false-postive results. Though they can be workarounded by using @class, that's not the proper way to solve the issue (In the use case of this example) Although I don't know how the improvement can be implemented, but that's not my concern 😂

The reason why I stand for Linter Should Work According to Language Specifications is that:

However I am not sure if I understand this statement 😕 Any valid lua code by itself, conform to the Language Specifications. For example

• trailing spaces
• empty if branch
• code cannot reach
• ... more and more

Then are you saying that all kind of these check should be disabled by default 😳 ?

Following is a bit off topic, but there are a few points I want to add:

• In my team we also set up luacheck which is another linter that do file-based analysis
• it also has duplicate-index check

local t = { --> unused variable 't'
    a = function () end,  --> value assigned to field 'a' is overwritten on line 3 before use
    a = 2,
}
function t:a() end --> no warning

• clearly when writing table literal, defining the same field twice is probably a mistake => warning
  Maybe this is what you want to express: if linter want to enforcing rules, it should work perfect and correct as it is ? 🤔

PS: Please be reminded again that I am just a user / contributor of luals, I am not maintainer. All the above are my own opinions which cannot represent maintainers' view. I don't want to give you a feeling that luals community doesn't welcome new issues 🙏 I tried to give my reasoning as detailed/logical as I can when I reply you. 😄

Yes, that is a good ending.

Thank you for your understanding and support!

Above all. The opinion about:

**all kind of these check should be disabled by default
Is no way to do and I don't agree so.

I mean some of the check should have an alternative tool as you said aka luacheck.

So I just make a PR to disable two of the check (duplicated-index and duplicated-set-field) instead all of the check.

The reason to disable the two of the check is that it bothers the table or we can also recognized as object to let the method override / shadowed in child object.

And I also mentioned that it would switch back to enabled while LuaLS solve that defect and the bug being fixed.

[lewis6991]

We code for Lua, not for LuaLS style.

I'm not sure this tool is for you. LuaLS requires annotations so it understands the intention of the code. If you don't want to supply those annotations then LuaLS won't be very useful as many features won't be able to work.

I suggest you look into other tools.

[Keyslam]

We code for Lua, not for LuaLS style.

For LuaLS to provide the features that it does it must add new concepts to the language (even if those are marked with just annotations), because Lua as a language is way too dynamic otherwise. If you don't want to conform to that, then why are you using LuaLS?

[jakitliang]

We code for Lua, not for LuaLS style.

For LuaLS to provide the features that it does it must add new concepts to the language (even if those are marked with just annotations), because Lua as a language is way too dynamic otherwise. If you don't want to conform to that, then why are you using LuaLS?

If you want to add new concepts to the language, why not introduce a new programming language?

Just write a new programming language instead.

Language server is born for linting and help developers to check and giving advices for solve their problem instead of adding concepts to the language.

I think you should learn what LSP is and what LSP born for.

[jakitliang]

We code for Lua, not for LuaLS style.

I'm not sure this tool is for you. LuaLS requires annotations so it understands the intention of the code. If you don't want to supply those annotations then LuaLS won't be very useful as many features won't be able to work.

I suggest you look into other tools.

I don't think LuaLS have so much functionalities that requires annotations and emphasize that this tool forces user to giving annotations.

LuaLS lacks a way to treat the variable that holds the return value as a new anonymous type that automatically inherits from the return type

Since it have such defect so it should suspend or disable as default some of the functionalities of diagnostic check in current version.

When it finish its type system so the diagnostic check can get back.

I want to solve the problem instead of telling the emotions.

I suggest you look into other programming language.

[sumneko]

这确实是一个bug，是由于3.0版本的实现缺陷导致的，可能没有简单的办法修复它。因此你可以直接禁用掉这个诊断。
如你所见我现在没有时间精力进行维护工作，因此可以通过禁用/注解绕过的问题目前基本都是低优先级状态。

[Issues-translate-bot]

Sumneko Lua translate bot

---

This is indeed a bug, caused by an implementation flaw in version 3.0, and there may be no easy way to fix it. Therefore you can simply disable this diagnostic.
As you can see I don't have the time or energy to do maintenance work right now, so the issues that can be bypassed by disabling/annotating are basically low priority at the moment.

[jakitliang]

这确实是一个bug，是由于3.0版本的实现缺陷导致的，可能没有简单的办法修复它。因此你可以直接禁用掉这个诊断。 如你所见我现在没有时间精力进行维护工作，因此可以通过禁用/注解绕过的问题目前基本都是低优先级状态。

感谢，所以我才会说这个事情

再次感激 苏美果大人亲自出面，辛苦！

[Issues-translate-bot]

Sumneko Lua translate bot

---

This is indeed a bug, caused by an implementation flaw in version 3.0, and there may be no easy way to fix it. Therefore you can simply disable this diagnostic. As you can see I don't have the time or energy to do maintenance work right now, so the issues that can be bypassed by disabling/annotating are basically low priority at the moment.

Thanks, that's why I'm talking about this

Thanks again to Mr. Sumeiguo for coming out in person, thank you for your hard work!