"Unknown type conversion variable"

[PinewoodPip]

I frequently run into the issue of being unable to cast fields when calling constructors of a base class from a derived one, and I'm not sure if I'm doing something wrong. Here's a case that (I think) should work, however it doesn't. As a result I also get the diagnostic for wrong return type afterwards.

---@class MyClass
local MyClass = {}

---@class MyDerivedClass : MyClass
local MyDerivedClass = {}

---@return MyClass
function MyClass.Create()
    return {}
end

---@return MyDerivedClass
function MyDerivedClass.Create()
    local instance = MyClass.Create() ---@cast instance MyDerivedClass

    return instance
end

The code is of course for demonstration purposes of the issue and not a functional OOP example.

Would like to know if I'm doing something wrong or if this is a bug.

[carsakiller]

That's odd, I copied your example and everything seems to be working:

Perhaps something in your configuration is acting up?

[PinewoodPip]

Interesting. After giving it a second look, it seems like the issue is inconsistent. There are many parts of my codebase that are set up similarly to the example, and some of them have this issue, while others do not.

Here are my settings from VSC (omiting personal stuff like Lua.workspace.library and Lua.workspace.ignoreDir), I would appreciate if you tried the example with them to see if it happens then (if that's what you meant by "Perhaps something in your configuration is acting up?"):

    "Lua.completion.autoRequire": false,
    "Lua.type.castNumberToInteger": true,
    "Lua.hint.setType": true,
    "Lua.diagnostics.severity": {
        "cast-local-type": "Hint",
        "trailing-space": "Information!",
        "redefined-local": "Warning",
        "need-check-nil": "Error",
        "deprecated": "Information",
        "duplicate-set-field": "Information",
        "assign-type-mismatch": "Information",
        "redundant-return-value": "Warning",
        "unbalanced-assignments": "Error!",
        "redundant-value": "Error!",
        "code-after-break": "Error!",
        "param-type-mismatch": "Information"
    },
    "Lua.diagnostics.groupSeverity": {
        "unused": "Warning",
        "ambiguity": "Warning"
    },
    "Lua.diagnostics.disable": [
        "need-check-nil"
    ],
    "Lua.type.weakNilCheck": true,
    "Lua.diagnostics.workspaceRate": 30,
    "Lua.workspace.maxPreload": 50000,
    "Lua.workspace.preloadFileSize": 5000,
    "Lua.diagnostics.globals": [
        "LibStub"
    ],
    "Lua.doc.protectedName": [
        "__[A-Z]*",
        "__[a-z]*"
    ],
    "Lua.hover.expandAlias": false,
    "Lua.type.weakUnionCheck": true,
    "Lua.doc.privateName": [
        "_[a-z]*",
        "_[A-Z]*"
    ],
    "Lua.diagnostics.workspaceDelay": 2000,

I stripped out the settings that are not from the extension, hopefully I didn't miss any.

[carsakiller]

I don't see anything obvious in your config. Could you provide an example from your codebase where the issue is consistent?

[PinewoodPip]

Forgive me, I have forgotten to offer a follow up to this. The issue does continue to plague my workspace, however today I have possibly discovered what triggers it. It seems that it affects only functions at the very end of the file.

If I use the example code posted in the original post, the issue is triggered, but it disappears if I add any character, even whitespace, after the function end. See the video for demonstration.

2023-08-28.10-16-42.mp4

When you tried the example code you added a local inst = .... at the end; could you re-test it without adding any characters after the function's end?

If you or anyone else is able to recreate it that way, I'll convert this post to an issue.

[ChrisKader]

I see the yellow lines disappear but does the instance variable provide any intell-isense from a mouseover? How about the function that returns the value?

Its a pretty popular best practice to end files with a single line break and I am curious if that's what's happening here.

When I test your code in a new document that has a line break at the end of the file, it seems to have no issues with type info.

[SpectralCathe]

@PinewoodPip made me repro this, empty line at the end of file "fixes" it, literally 1997

[carsakiller]

This can be tracked in #2326.