Problems after updating to 3.x version

[rgarat]

Describe the bug
I noticed that the plugin was not working correctly it stopped responding to autocomplete requests, failed to detect changes in code (create a local variable, it was marked as unused, then started using it and it was not marked as used)
The workspace diagnosis never seems to finish, the info in the bottom bar of vscode seems to be in progress/waiting

I went back and installed the 2.6.7 version and it started working again.

To Reproduce
Steps to reproduce the behavior:

1. Open my code with the new version of the plugin installed, and try to work in lua code.

Expected behavior
The plugin worked fine with the old version

Environment (please complete the following information):

• OS: macOS
• Client: VSCode

Additional context
This project contains a few huge 20k lines files that are used to declare the content of the game and they have a liberal reuse of local variables to declare a big number of entities (here in this sample code, tt is a table that gets replaced for a new one on each E:register_t call, but the local variable is reused and the lua-language-server analysis reports all its fields used on all the different templates, I suspect this might be causing some issues for the plugin)

`
tt = E:register_t('aura_metropolis_portal','aura')
tt.main_script.insert = scripts.aura_apply_mod.insert
tt.main_script.update = scripts.aura_apply_mod.update
tt.aura.duration = -1
tt.aura.mod = 'mod_metropolis_portal'
tt.aura.cycle_time = fts(1)
tt.aura.radius = 35
tt.aura.vis_bans = bor(F_FRIEND, F_BOSS)
tt.aura.vis_flags = bor(F_TELEPORT)

-- mod_metropolis_portal
tt = E:register_t('mod_metropolis_portal', 'mod_teleport')
tt.modifier.vis_flags = bor(F_MOD, F_TELEPORT)
tt.max_times_applied = nil
tt.jump_connection = true
tt.delay_start = fts(2)
tt.hold_time = 0
tt.fx_start = 'fx_teleport_metropolis'
tt.fx_end = 'fx_teleport_metropolis'

-- fx_teleport_metropolis
tt = E:register_t('fx_teleport_metropolis','fx')
tt.render.sprites[1].name = 'fx_teleport_metropolis'
tt.render.sprites[1].size_scales = {vv(0.83),vv(1),vv(1.5)}

`

Thanks for any help

[rgarat]

Reinstalled the 3.0.1 version, the problems happened again, adding log and some screenshots of how it fails

luavscode.log

When trying to autocomplete it gets stuck like this

and in the bottom bar it remains like

[nshen]

3.x break my Neovim config.
how to fix neovim?

[sumneko]

Could you please checkout this version and test if it fixed: https://github.com/sumneko/lua-language-server/actions/runs/2167773077
You only need to replace the script folder

[rgarat]

I did some basic tests and it seems to work, the workspace analysis ends and autocomplete works.
Will test it a bit more on monday when I get to work again.
Thanks for the quick response

[sumneko]

Please checkout 3.0.2

[rgarat]

I tried 3.1.0 it seems to work fine, regarding the first reported thing, but I noticed that some other stuff got lost in the upgrade, I will add it here to reuse the context, let me know if you want a separate issue.

In the same project when I was writing code and trying to autocomplete, it would take into account the existing code in the tables. But the new version wont suggest stuff that is used before it.

With 2.6.8 you can see that the autocomplete sees all child items as "any" and suggests the items used previously

and if you keep getting deeper it still works

With 3.1.0 you can see that the types of the children of tt are "unknown" and autocomplete stops working when going deeper

The way the tt tables are defined is by inheriting from another table definition and by adding child tables as fields that are pre registered.

So in this image, tt will contain all the items from the decal_scripted template and the content of the tables idle_fip, soldier, unit as children as well.

Thanks for your help.

[sumneko]

Please see #980 , dose not trace field inject in 3.X.

[rgarat]

Is this something that doesn't work for now? or will this never be supported?

What is the reasoning behind losing this support?

[sumneko]

I think it will never be supported.

1. It has a high performance overhead. I need to check whether there is an assignment behind each reference, and then recursively check the assignment of the assignment.
2. There will be complex circular reference problems, and in order to solve the circular reference, more additional overhead is required.
3. This conflicts with future type checking. I can't judge whether you are injecting a field into a class or setting a field that shouldn't exist.

[rgarat]

How about having it be an optional feature?
Perhaps tag the local variable, or the return of a method as closed or open with closed by default?

[sumneko]

How about having it be an optional feature? Perhaps tag the local variable, or the return of a method as closed or open with closed by default?

I looked at your screenshot again. It seems that I misunderstood your question.
This should be a bug, I will fix it.