TL;DR

The introduction of the is_circular_reference function call within the for loop of stages/resolve_locals.lua since version v0.26 seems to significantly impact performance as observed in this commit: a24332e

The long story

Greetings, I've been utilizing luacheck v0.25 via luarocks in a private project for an extended period. Within this project, there exists a sizable Lua file (>100K lines) primarily comprising data tables (~95%) interspersed with logic code (~5K lines). Under version v0.25, linting this file takes approximately 10 seconds, which is acceptable given its substantial size.

However, subsequent to updating to the latest release, luacheck v1.1.2, the linting process for this file consumes over 10 minutes. Further investigation revealed that this performance regression commenced with v0.26.

Upon analyzing the differences between v0.25 and v0.26, I attempted to revert the alterations near the aforementioned for loop. Consequently, the linting time returned to normal, averaging around ~10 seconds.

How to reproduce

Given the private nature of the project, sharing the actual file is not feasible. Instead, I will outline the file structure and provide a minimal test file capable of reproducing the issue.

File Structure:

-- Standard module require
local abc = require "abc"
...

-- Approximately 200 local function definitions used by the data table below
local function handlerA(...)
    ...
end

-- Over 5000 data templates formatted as { [id] = <template> }
local DATA = {
    [id] = {
        -- Approximately 20 attribute fields for each data template
        attr1 = 1,
        attr2 = "2",
        attr3 = true,
        ...
        -- Not all templates have `on_use`; roughly 50% of templates include it
        on_use = function (self)
            -- This section references the local functions defined above
            return handlerA(...)
        end,
    },
    ...
}
return DATA

Observations

• Removing the entire local DATA = {...} portion, leaving only the local function definitions (~5K lines), results in a lint time of ~1 second for both luacheck versions.
• Conversely, removing the entire local function definitions, leaving only the local DATA = {...} (~95K lines), yields a lint time of ~8 seconds for both luacheck versions.
• Combining both parts causes luacheck v0.26 to take 10+ minutes.
• Additionally, removing all on_use functions from the data templates, such that none of them have upvalues pointing above, leads to a lint time of ~1 minute for luacheck v0.26.

Minimal Reproducing File

I have crafted a gen_test.lua script to generate a test.lua file in the aforementioned format:

local NUM_FUNCS = 50    -- control num handlers to be generated
local NUM_DATAS = 200   -- control data templates to be generated
local NUM_ATTRS = 10    -- control attributes count of each data template

local f = io.open("test.lua", "w")

-- gen handlers
for i = 1, NUM_FUNCS do
    f:write(("local function handler%03d(...) return ... end\n"):format(i))
end

-- gen datas
f:write("local DATA = {\n")
for id = 1, NUM_DATAS do
    f:write(("    [%d] = {\n"):format(id+10000))
    for attr = 1, NUM_ATTRS do
        f:write(("        attr%02d = 0,\n"):format(attr))
    end
    f:write(("        on_use = function (...) return handler%03d(...) end,\n"):format(
        NUM_FUNCS > 0
            and id%NUM_FUNCS + 1
            or 0
    ))
    f:write("    },\n")
end
f:write("}\n")
f:write("return DATA\n")

On my MacBook Pro 2016, v0.25 takes less than 1 second while v0.26 takes around 30 seconds.

Thoughts

I acknowledge that this file structure may be unconventional, but refactoring is challenging within the project. I aim to lint this file given the presence of logic code in the upper portion and the inline on_use functions in the data templates. Are there alternative suggestions on how to work around or disable the newly added circular reference check? Could the is_circular_reference() function be optimized, perhaps by caching the result of a checked node?

Your assistance in addressing this performance concern would be greatly appreciated.