 |
lua-l archive |
|
|
||
|
Am 30.04.2013 01:55 schröbte Luiz Henrique de Figueiredo:
But the best parser is, well, Lua itself!! Deep inside Lua is a block of code that knows when it has a global variable and converts "x" to "_ENV.x" .. that's fundamental to the way the language works now. It seems to me that the best approach would be to modify luac and add a switch to get it to emit a line of output each time it prefixes "_ENV" onto a global/free variable. Something like the line number, column number, and variable name. With this as input, it should be easy to create analysis tools that then provided information on globals usage (that mis-spelled global would easily be found).See this thread and the ones it links to for a roadmap: http://lua-users.org/lists/lua-l/2011-09/msg00684.html
Is this really a problem? How often do you use a variable named _ENV to access a regular table with fields *not* intended to be used as global variables? So the distinction "global x" vs. "_ENV.x" is mostly meaningless, IMHO, and it is easy to search for the latter with current tools.
The problem is to identify those pieces of code that are not regular Lua code[*], and to adapt the globals reporting accordingly (like disabling it for those parts, or reporting warnings instead of errors, or loading a different list of allowed names if possible).
[*] Lua code using (only) the well-known globals from Lua's standard library.
Philipp