[Bug]: Sequential table of a struct generates `Structures/X[]` instead of `X[]`

[AmyJeanes]

Summary

When a wiki argument or return is a sequential table of a struct, the generated element type keeps the wiki page path instead of the class name - Structures/LocalLight[] rather than LocalLight[].

The classes themselves are declared plain (---@class (partial) LocalLight), so the annotated type resolves to a non-existent class Structures, taking the [] with it, and a correctly-typed argument is rejected:

warning: expected `Structures?` but found `LocalLight[]`.  [param-type-mismatch]

A non-sequential struct reference converts correctly, which is what points at the sequential form specifically:

-- util.lua:988 - correct
---@param traceConfig Trace A table of data that configures the trace. See Structures/Trace for available options.

The wiki is right in each case. render.SetLocalModelLights documents the argument as:

1 sequential table<LocalLight structure> lights = {}

Affected annotations

All occurrences at gluals-annotations-prerelease @ 9e973c4:

-- render.lua:1026
---@param lights? Structures/LocalLight[] A table containing up to 4 tables for each light source ...

-- game.lua:79
---@return Structures/Sky3DParams[] # The 3D skybox info, ...

-- util.lua:280
---@return Structures/ModelMeshData[] # Each index in this table corresponds to a mesh ...

-- util.lua:283
---@return Structures/BoneBindPose[] # This tables indices are bone IDs ...

Minimal repro

Repro zip: structures-path-type-repro.zip

annotations/render.lua and annotations/structures.lua are those files verbatim from 9e973c4, and they are the only annotation files needed.

-- repro.lua
---@type LocalLight[]
local lights = {}

render.SetLocalModelLights(lights)

warning: expected `Structures?` but found `LocalLight[]`.  [param-type-mismatch]  --> repro.lua:10

Version behaviour

To be accurate about this: the annotation is wrong on every version, and the repro above reports identically on glua_check 1.1.1 and 1.1.2. It is not an analyzer regression.

What changed for us is only when real code reaches it. On 1.1.1 our arguments were inferred loosely enough that the check never ran; 1.1.2 resolves them concretely - e.g. { [1] = { color = Vector, pos = Vector }, ... } - and the mismatch then surfaces. So this went from latent to build-failing across three of our addons on the same annotations.

Real-world impact

render.SetLocalModelLights is called in three separate addons here, each now failing --warnings-as-errors on 1.1.2. The three @return sites don't currently fire for us, but look like the same conversion path.

The workaround in use is a local override, which would be good to delete:

---@param lights? LocalLight[]
function render.SetLocalModelLights(lights) end

Expected

Structures/LocalLight[] is generated as LocalLight[] - the class name, matching how the non-sequential form already converts.

Environment

• glua_check / glua_ls 1.1.2 (and 1.1.1 - same result)
• annotations gluals-annotations-prerelease @ 9e973c4
• Windows 11

---

Disclosure: this report was researched and written by Claude Code working in my repositories. Every claim in it was reproduced and verified against real workspaces rather than asserted - building the repro is what corrected an earlier draft of this report that wrongly blamed a 1.1.2 regression - and the two of us went through the findings together before I filed it. Happy to narrow anything further if that would help.