mpeterv
warn when use undefined variable of table
Hi~~ Like:
local tableTemp = {}
tableTemp.value1 = 12;
local iValue = tableTemp.value1 + 12 -- here is ok
iValue = tableTemp.value2 + 12 -- here is an error
when use undefined variable of table
I'll try to implement a very simple variant of this in one or two versions. Basically, for each value assigned to a local variable that can be accessed only through that variable, it will find all set and accessed fields, and about accesses of fields that were never set. So, it will detect issue in 'local t = {}; print(t.a)' but not in 'local t1 = {}; local t2 = t1; print(t2.a)' or 'local t = {}; print(t.a); t.a = 0'. I could try and make it more clever but then it would get very close to type inference, and I'd rather build that from the ground up instead of putting more ad-hoc hacks into luacheck.
get it. some cases are complicated.If do more,it will make it like type inference.lke: local t={} t.str1="12" t.int1=123 local test = t.int1 + t.str1 concatenate int with string. if you try to detect this,As you say,it will like type inference.
^-^
Recently, I fixed several bugs in my codebase related to undefined table variables, It was surprising to me that luacheck did not automatically alert me to this beforehand. After a period of several frustrating hours in which I assumed that my luacheck implementation was bugged, I then found this GitHub issue and realized that the feature just doesn't exist. ><
@mpeterv Any updates on this? Having this feature would be a tremendous boon, as is it my understanding that many variables of big projects are scoped to the module (table) level.
Also, the ability to find UNUSED table variables (across multiple files) is also sorely needed!
Thank you for your work on luacheck.
@Zamiell I plan to add simple unused and undefined table field detection in the next version, I hope to release it by the end of the next week.
This will take a bit more time as I decided to implement flow-based detection, so that at least usage before definition is detected. However, this detection still works only in the scope of the local variable holding the table. As soon as the table is passed somewhere else, e.g. into a function, no warnings will be produced from that point to avoid false positives. Same if the initial value of the table comes from a function or anything other than a table literal.
So this detection won't help with, say, typos in names of methods of objects or functions in modules imported with 'require'. However, it will detect typos in names of functions defined in the file being checked. In the future luacheck could cross- reference information about what functions each module exports and detect typos in fields of 'required' modules, too.
Not yet, I'm sorry, I've had to postpone this. Mainly because quite a lot of effort for something that detected undefined fields only in some limited cases.
this would be absolutely amazing if it worked across files and function calls. Being able to detect this case within a file is slightly useful, but for bigger projects the lack of a type system in lua can really slow down development. Also makes refactoring across several files extremely dangerous. The false positives is for sure an issue, especially since a lua table can be created via an unparsable binary module. Perhaps the way to avoid false positives would be only throw an error if the source of a table is unique, or if all table sources have the problem.
