Type information lost when file adding a member to a global table is opened (LSP didOpen)

[sparr]

Given the following four files, language server behavior in d.lua works as expected until c.lua is opened (i.e. didOpen is sent via LSP), at which point GlobalTable.Namespace loses type information and becomes just unknown.

a.lua

---@meta
GlobalTable = {}

b.lua

_G.GlobalTable = _G.GlobalTable or {}

c.lua

GlobalTable.Namespace = {}
GlobalTable.Namespace.Var = 1

d.lua

local v = GlobalTable.Namespace.Var

This misbehavior has been reproduced in emmylua_ls 0.24.0 and 0.25.0 within the VSCode extension, and also through a LLM-generated LSP client communicating directly with emmylua_ls 0.25.0 while reducing this to a test case.

I originally encountered this problem when working with https://github.com/beyond-all-reason/Beyond-All-Reason/blob/92b74af2ba0347ebcef739b8956b9ee6921f44f3/spec/spec_helper.lua#L41.

[CppCXY]

Removing this line _G.GlobalTable = _G.GlobalTable or {} should fix the issue.

[CppCXY]

We do not recommend the definition method _G.X = _G.X or xx, because it indicates that the project is unclear about the definition order of variables, and global variables may lack a single definition source, which can cause errors in the association of related fields.

[sparr]

While I understand that this may not be a best practice, it still seems like a bug for the analyzer to behave differently depending on the order in which the files are opened.

[CppCXY]

There are some historical bugs here. After global variables are defined as _G.xx, they seem to stop working properly. Additionally, the reason why the behavior related to global variables may depend on the order in which they are opened is mainly that global variables can be defined anywhere, making it impossible for us to make more accurate assumptions. Therefore, the best approach is to ensure that each global variable has at most one definition and is immutable. Changing the current situation will require changes across multiple versions and cannot be done immediately.

[sparr]

they seem to stop working properly

That "seem" is somewhat the point of this bug report. This behavior was mysteriously opaque to me, with resolution working and then failing within the same session even when I had made no changes to any file. At the very least, this will serve to document this [mis]behavior.