-
-
Notifications
You must be signed in to change notification settings - Fork 331
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
Nested property type lost when accessed from reference #1613
Comments
Related: #1561 |
You can not inject fields in this way, use the follow way instead. ---@class B
local B = {}
B.property2 = C() |
that was just the example, but this sort of behavior manifests itself when you use a reference to a property regardess of how injected field is done. A.property1.property2 <--- correctly knows property or type... Here is another example. test(A.property1) function test( ref ) |
this happens for me when I have a deeply nested property, then want to use a reference to make code smaller / clean vs always using the full. please consider taking closer look. |
You can change your code to local A = {}
---@class B
---@overload fun(): B
local B = {}
---@class C
---@overload fun(): C
local C = {}
---@class B --> add this annotation
A.property1 = B()
A.property1.property2 = C()
local refToB = A.property1
local refToC = refToB.property2 |
@lunarwtr has your issue been resolved? |
Kind of.. I can apply type annotations in every function, but that is not ideal. None the less I appreciate your work on this. Here is real example.. In constructor define something.. typing looks perfect. Then in all other functions type is lost. I can do as sumneko suggests and reassign the unknown to a variable with typing. |
The type is also lost when inside a table. OpenRA/vscode-openra-lua#10 |
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
Expected Behaviour
while the local
refToB
is correctly of typeB
, it no longer is aware of property2.expected behavior would be that it is aware of the properties assigned to the instance.
Actual Behaviour
presence of property is lost in the "instance" of object B (not definition).
Reproduction steps
Additional Notes
No response
Log File
No response
The text was updated successfully, but these errors were encountered: