Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not shadow/re-inject fields in child-classes #2573

Open
Luke100000 opened this issue Mar 17, 2024 · 2 comments
Open

Do not shadow/re-inject fields in child-classes #2573

Luke100000 opened this issue Mar 17, 2024 · 2 comments

Comments

@Luke100000
Copy link
Contributor

Luke100000 commented Mar 17, 2024

How are you using the lua-language-server?

Visual Studio Code Extension (sumneko.lua)

Which OS are you using?

Linux

What is the issue affecting?

Diagnostics/Syntax Checking

Expected Behaviour

When assigning to a field which is already defined in one of it's supers, no injection should be used.

Actual Behaviour

Assigning to existing field is not possible as I effectively end up with two fields A.test and B.test.

The only valid workaround I know would be using setters in A.

Just disabling (exact) does not solve the issue, just disable the warning.

Reproduction steps

---@class (exact) A
---@field test number
local a = {}

function a:init()
    --This is fine
    self.test = 0
end

---@class (exact) B : A
local b = {}

function b:init()
    --This is an injection and thus invalid
    self.test = 0
end

Additional Notes

If shadowing a field is explicitly wanted, one can still define/type explicitly. But I think by default, no additional field should get injected.

Issue is a bit related to @override (#2569).

Log File

No response

@Luke100000
Copy link
Contributor Author

I added a fix for this, but because I have honestly no idea what I'm doing its probably not a proper solution. It works for me tho: Luke100000@ad80ae9

It effectively disables looking for local field definitions for exact classes. They are invalid anyways afaik.

@alex-courtis
Copy link

Confirmed fix on 3.10.5.

Inherited fields and types are correctly identified.

Appreciate your work @Luke100000 - I'd me most grateful if you raised a pull request for the fix.

20240908_141729

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants