Recently we've been talking about globals and how the undisciplined use of them can cause problems for both Lua application developers and for casual scripters. lglob is a practical demonstration of how static code analysis can go a long way to relieve anxiety and get more compile-time feedback. The technique is discussed in David Manura's excellent wiki entry on detecting undeclared variables:
In particular, it's derived from his globalsplus.lua script, which uses luac output to track globals, and the _fields_ of globals, so 'math.sine' is also an error.
Jay alluded to the difference between 'formal' and 'informal' use of Lua, and I don't believe that all Lua code needs to meet formal standards. By default it is strict:
$ cat > script.lua
function dump(x)
print('value is '..tostring(x))
end
dump (42)
$ lglob script.lua
lglob: script.lua:1: undefined set dump
lglob: script.lua:5: undefined get dump
But the '-g' (for globals) flag accounts for globals defined in a script:
$ lglob -g script.lua
(fine)
(It's not currently checking that a global is defined at the _point of usage_, however, but this remains a work in progress)
By default, lglob uses the 'usual' contents of _G, but you can add whitelists to do this using the '-w' flag, an exclusive whitelist with the '-wx' flag, or a blacklist with '-b'. (These files are straightforward files containing Lua assignments). By default, it tracks use of require() and local aliases to modules; you can use the -wl whitelist to statically define the meaning of require().
Just type 'lglob' for the full set of arguments, and read the readme. It has a lot of options because lglob is meant to be customizable to meet your needs, and not just impose a one-fits-all solution on all Lua files.
Until lglob gets into main LuaRocks repo, use:
steve d.
