Easiest with an example:

$ cat t.lua 
print("hello world")

$ luacheck -q --std none t.lua 
Checking t.lua                                    1 warning

    t.lua:2:1: accessing undefined variable print

Total: 1 warning / 0 errors in 1 file

Expected behaviour so far. But if I add the std none as an inline directive, it has no effect:

$ cat t.lua 
--luacheck: std none
print("hello world")

$ luacheck -q t.lua 
Total: 0 warnings / 0 errors in 1 file

Similar to #63

At work we've hit code that has more than the maximum number of local variables. Automated testing caught this but I think luacheck could have caught it for us as well. I believe the default limit is 200 local variables for a scope.

And since someone could technically compile lua with a different value, I think if we are going to check for this we should have a configuration option for what the maximum number of locals threshold is.

Hello Peter,

There is a way via command line to just disable this setting? On our (kinda old) code I need to expose some globals in a module. There is a way to disable this check via command line args?

I still want to check for accessing global variables (I don't want --no-global)

Example:

-- test.lua
function bar() end
foo()

Checking test.lua                        Failure

    test.lua:1:10: setting non-standard global variable bar
    test.lua:2:1: accessing undefined variable foo

Total: 2 warnings / 0 errors in 1 file

I just want one warning on this (accessing undefined variable foo)

luacheck does not detect this misplaced semicolon which casues a parse error under Lua 5.1:

if somecondition then; -- see that semicolon?
    do some_stuff() end
end

This is however legal syntax in Lua 5.2, but I think it should at least warn about the empty statement.

Incorrect warning with following code?

local function addone(n)
    return n+1
end
local a = 0
while true do
    a = addone(a)
end

we have support for declarations of local variables shadowing previous declarations within the current scope. It would be useful to have a flag that warns when one shadows variables defined in global scope

ex

local type = "some string"

would warn as we are defining a local variable type which shadows the global std lib type function

type = "some string"

would not warn (depending on if you have configured luacheck to allow globals)

I debug and found tonumber("0xC0.0") is nil in lua5.1, which is 192 in luajit or lua5.2

Critical error: Luacheck 0.14.0 bug (please report at github.com/mpeterv/luacheck/issues):
...n\Desktop\luacheck\bin\..\src\luacheck\linearize.lua:559: attempt to compare nil with number
stack traceback:
        ...gchen\Desktop\luacheck\bin\..\src\luacheck\utils.lua:162: in function <...gchen\Desktop\luacheck\bin\..\src\luacheck\utils.lua:159>
        ...n\Desktop\luacheck\bin\..\src\luacheck\linearize.lua:559: in function 'node_to_lua_value'
        ...n\Desktop\luacheck\bin\..\src\luacheck\linearize.lua:573: in function 'scanner'
        ...n\Desktop\luacheck\bin\..\src\luacheck\linearize.lua:479: in function 'scan_expr'
        ...n\Desktop\luacheck\bin\..\src\luacheck\linearize.lua:485: in function 'scan_exprs'
        ...n\Desktop\luacheck\bin\..\src\luacheck\linearize.lua:432: in function '?'
        ...n\Desktop\luacheck\bin\..\src\luacheck\linearize.lua:281: in function 'emit_stmt'
        ...n\Desktop\luacheck\bin\..\src\luacheck\linearize.lua:286: in function 'emit_stmts'
        ...n\Desktop\luacheck\bin\..\src\luacheck\linearize.lua:658: in function 'build_line'
        ...n\Desktop\luacheck\bin\..\src\luacheck\linearize.lua:685: in function 'linearize'
        ...gchen\Desktop\luacheck\bin\..\src\luacheck\check.lua:192: in function <...gchen\Desktop\luacheck\bin\..\src\luacheck\check.lua:189>
        ...
        (tail call): ?
        ...gchen\Desktop\luacheck\bin\..\src\luacheck\utils.lua:261: in function 'map'
        ...ngchen\Desktop\luacheck\bin\..\src\luacheck\main.lua:374: in function 'get_new_reports'
        ...ngchen\Desktop\luacheck\bin\..\src\luacheck\main.lua:419: in function 'get_reports'
        ...ngchen\Desktop\luacheck\bin\..\src\luacheck\main.lua:512: in function <...ngchen\Desktop\luacheck\bin\..\src\luacheck\main.lua:28>
        [C]: in function 'xpcall'
        ...ngchen\Desktop\luacheck\bin\..\src\luacheck\main.lua:538: in main chunk
        [C]: in function 'require'
        ...Users\yongkangchen\Desktop\luacheck\bin\luacheck.lua:2: in main chunk
        [C]: ?
stack traceback:
        [C]: in function 'error'
        ...gchen\Desktop\luacheck\bin\..\src\luacheck\utils.lua:181: in function 'pcall'
        ...gchen\Desktop\luacheck\bin\..\src\luacheck\check.lua:209: in function <...gchen\Desktop\luacheck\bin\..\src\luacheck\check.lua:208>
        (tail call): ?
        ...gchen\Desktop\luacheck\bin\..\src\luacheck\utils.lua:261: in function 'map'
        ...ngchen\Desktop\luacheck\bin\..\src\luacheck\main.lua:374: in function 'get_new_reports'
        ...ngchen\Desktop\luacheck\bin\..\src\luacheck\main.lua:419: in function 'get_reports'
        ...ngchen\Desktop\luacheck\bin\..\src\luacheck\main.lua:512: in function <...ngchen\Desktop\luacheck\bin\..\src\luacheck\main.lua:28>
        [C]: in function 'xpcall'
        ...ngchen\Desktop\luacheck\bin\..\src\luacheck\main.lua:538: in main chunk
        [C]: in function 'require'
        ...Users\yongkangchen\Desktop\luacheck\bin\luacheck.lua:2: in main chunk
        [C]: ?

Hi,

I got mismatched line number (e.g., all shows shadowing upvalue XXXX on line 7) when enabling cache. Modifying Lua files or Recreating the cache will solve this issue temporarily.

Is it a caching bug?

Local _ can be used as a placeholder and is not reported when redefined or unused. However, if it's declared without initial value and then never set or used, it's completely useless and should be reported anyway. This sometimes happens if _ is used as a placeholder but then code is refactored and it's no longer needed.

See https://travis-ci.org/daurnimator/lua-http/jobs/112572318

Checking http/tls.lua                             2 warnings
    http/tls.lua:331:2: value assigned to field TLS_PSK_WITH_AES_128_GCM_SHA256 is unused
    http/tls.lua:332:2: value assigned to field TLS_PSK_WITH_AES_256_GCM_SHA384 is unused

The code in question: https://github.com/daurnimator/lua-http/blob/3fe22b16bd8351c4796e1eb0a3a6ab512dfda40d/http/tls.lua#L331

I'm building a sublime text plugin to check lua code with luacheck. There is a way to give luacheck a config file or having per file notations? I'm using jshint for my js scripts and it's great to have configs per file (most common case, different globals per file requiring different rocks).

It's something that you have in mind to do? Thanks!

Hi there,

Could you please provide an example of how the --globals option is used? I can't deduce it from the automatically generated doc nor looking at the source code (of luacheck or argparse).

I have tried many things. Imagine that I want to add two globals: inspect and xml. Here are some of my failed attempts.

luacheck --globals "inspect,xml" myfile.lua
luacheck --globalsinspect --globalsxml myfile.lua
luacheck --globals inspect --globals xml myfile.lua

It would be nice to be able to get the results in TAP or JUnit format in order to integrate luacheck with jenkins jobs.

For a good reference for TAP format, check: http://testanything.org/tap-specification.html
For more junit format information, check: https://svn.jenkins-ci.org/trunk/hudson/dtkit/dtkit-format/dtkit-junit-model/src/main/resources/com/thalesgroup/dtkit/junit/model/xsd/junit-4.xsd

It would be nice to report the error message and its line when the file being checked has a syntax error. So, instead of just this:

Checking d:\run.lua Syntax error

We get something like what we have with luac

luac: d:\run.lua:11: '=' expected near 'foo'

I use luacheck with ST3. More than often, I make a syntax error and luacheck stops parsing the file I'm working on. Since I have no indication, I have no idea something is broken somewhere.

Thanks in advance!

Can we have pattern (wildcard) match in per file config in .luacheckrc?

I want to do some overwrite for my rockspec files.
but the rockspec file name are keeps changing from release to release.

Shall we do the follow to disable global check for all rockspec files?

--.luacheckrc
files['*.rockspec'].global = false

Currently linter-luacheck use the last line to determine the issue type:

If i got:

Checking source.lua ....

    source.lua:136:10: ....
    source.lua:137:16: ....
    source.lua:156:20: ....

Total: x warnings / y errors in 1 file

The errors number y is 0, I think all issue reported is warnings.
Else if y is not 0 i think all issues are errors.

I think this way is not the best solution.

Can we have each report line like:

    source.lua:136:10: error: ....
    source.lua:136:10: warning: ....

So that I can parse the issue type (error or warning) from each line itself.

I see there is format_warning and format_error_msg we can add warning: and error: in the 2 function.

Windows 7 / lua / command line:

lua luacheck.lua --no-color myfile.lua
--> output works as expected
lua luacheck.lua myfile.lua
--[[-->
Fatal error: Luacheck 0.7.3 bug (please report at github.com/mpeterv/luacheck/issues):
...drew\src\mediacircus\x64\Release\lua\luacheck\format.lua:52: attempt to call a table value (upvalue 'ansicolors')
stack traceback:
        ...drew\src\mediacircus\x64\Release\lua\luacheck\format.lua:52: in upvalue 'format_color'
        ...drew\src\mediacircus\x64\Release\lua\luacheck\format.lua:76: in upvalue 'format_file_report_header'
        ...drew\src\mediacircus\x64\Release\lua\luacheck\format.lua:83: in function <...drew\src\mediacircus\x64\Release\lua\luacheck\format.lua:82>
        ...drew\src\mediacircus\x64\Release\lua\luacheck\format.lua:116: in function 'luacheck.format'
        x64\Release\luacheck.lua:279: in function <x64\Release\luacheck.lua:14>
        [C]: in function 'xpcall'
        x64\Release\luacheck.lua:294: in main chunk
        [C]: in ?
--]]

It appears that ansicolor may have changed for you, although I may have the wrong version. I'll check that now.

Also, ansicolors appears to be abandon-ware, replaced by https://github.com/hoelzro/lua-term, and it all looks like spewed garbage in windows. I'm not sure, but I think that lua-term works with windows.... i'm probably wrong about that...

Anyway, I suggest:

1: Disabling color output as the default behavior
2: Make ansicolor / lua-term an optional dependency, given that it doesn't add anything to the capability and many will appreciate not having to install it (those of us that can't use luarocks)

I will use the configuration feature or my yet to be written batch file to disable this, so nor harm and no foul.

Your work is much appreciated. This is an extremely helpful tool.

Using underscore (_) is a common Lua idiom to ignore unused variables. It is typically used to ignore some values on multiple-value returning functions:

local _, count = string.gsub(str, " ", " ")

As a result, it is possible to redefine _ many times in the same scope (sometimes even in the same line).

I suggest ignoring _ on the variable redefinition detection.

Just a suggestion I thought would be useful to check for:

local table = {
    key = "foo",
    key = "bar",
    ["key"] = "baz",  -- a little tricker to check I guess
}

Would be nice if luacheck would warn about this case, since I don't see it ever being useful, but Lua will not complain and just have table.key == "baz".

Basically, it would be really nice if Luacheck behaved like, for instance, JSHint.
Quoting from its docs:

In case of .jshintrc, JSHint will start looking for this file in the same directory as the file that's being linted. If not found, it will move one level up the directory tree all the way up to the filesystem root.

Currently, I'm using Luacheck with Sublime.

In developing some APIs, arguments to a function may not be used but are critical to matching the API the object defines.

Ex (horribly ugly to reduce line-height)

local a = { __index = {} }
local b = { __index = {} }
-- self ignored
function a.__index.apply_stuff(self, y, z)
    return y + z
end
-- z ignored
function b.__index.apply_stuff(self, y, z)
    return self.x + y
end

Perhaps using a _ suffix or prefix would be good to indicate parameters unused... probably via configuration option. Example w/ prefix applied:

local a = { __index = {} }
local b = { __index = {} }
-- self ignored
function a.__index.apply_stuff(_self, y, z)
    return y + z
end
-- z ignored
function b.__index.apply_stuff(self, y, _z)
    return self.x + y
end

The following snippet does not do anything useful with foo, yet it is not marked as "unused":

local foo = { ... }
foo.bar = 3

While technically correct, it would still be useful if such variables were marked in some way, similar to how locals are reported as "never accessed" when they are only assigned to.

Of course, one tricky part here is that Lua may do metatable magic in the general case. So this check can only apply to tables that are the direct result of a { ... } expression.

It would be nice to have an inline options for luacheck.

Something lile:

function test:fun() -- [luacheck-unused: self]
   print(jit.version) -- [luacheck-globals: jit]
end

function test:fun2() -- still get warned here...
   print(jit.version) -- still get warned here...
end

This is very useful because:

1. self here in test:fun() may be required by some other framework but I don't use it.
2. jit maybe only get use once here I don't want add it to command line options of config file.

When module or another globals-based system is used to implement modules, typically exported variables are set in the main chunk (top level scope) of module, and globals set inside functions indicate a bug which --allow-defined would ignore. It would be nice to have something like --allow-defined-top for such situations.

This is using my luacheck 0.11.0-1 debian package version [0]

$ ls core/
s2scmanager.lua
$ luacheck core/
Checking core/                                    I/O error

Total: 0 warnings / 0 errors in 0 files, couldn't check 1 file
$ luacheck core/s2scmanager.lua 
Checking core/s2scmanager.lua                     11 warnings

    core/s2scmanager.lua:21:1: setting non-standard global variable incoming_s2sc
    core/s2scmanager.lua:22:25: accessing undefined variable incoming_s2sc
    core/s2scmanager.lua:23:23: accessing undefined variable incoming_s2sc
    core/s2scmanager.lua:28:10: setting non-standard global variable new_incoming
    core/s2scmanager.lua:35:10: setting non-standard global variable new_outgoing
    core/s2scmanager.lua:54:22: unused argument type
    core/s2scmanager.lua:57:10: setting non-standard global variable retire_session
    core/s2scmanager.lua:58:8: shadowing upvalue log on line 18
    core/s2scmanager.lua:72:10: setting non-standard global variable destroy_session
    core/s2scmanager.lua:96:2: accessing undefined variable retire_session
    core/s2scmanager.lua:100:8: accessing undefined variable _M

Total: 11 warnings / 0 errors in 1 file

[0] http://anonscm.debian.org/cgit/pkg-lua/lua-check.git

Running luacheck on a Lua file in a subdirectory fails with an I/O error:

siffiejoe@Merkur:~/src/lua/u [SVN*] :) luacheck u/lenses.lua 
Checking lenses.lua                               I/O error

    lenses.lua: couldn't read: No such file or directory

Total: 0 warnings / 0 errors in 0 files, couldn't check 1 file
siffiejoe@Merkur:~/src/lua/u [SVN*] :( cd u
siffiejoe@Merkur:~/src/lua/u/u [SVN*] :) luacheck lenses.lua
Checking lenses.lua                               OK

Total: 0 warnings / 0 errors in 1 file
siffiejoe@Merkur:~/src/lua/u/u [SVN*] :) 

Going into the subdirectory and running from there works.

Also, the scm rockspec on LuaRocks.org seems to be outdated:

siffiejoe@Merkur:~/src/lua/u [SVN*] :) LANGUAGE=en_US.UTF8 luarocks-5.2 install --server=http://luarocks.org/dev luacheck
Warning: falling back to curl - install luasec to get native HTTPS support
Installing http://luarocks.org/dev/luacheck-scm-1.rockspec...
Using http://luarocks.org/dev/luacheck-scm-1.rockspec... switching to 'build' mode
Cloning into 'luacheck'...
remote: Counting objects: 128, done.
remote: Compressing objects: 100% (94/94), done.
remote: Total 128 (delta 1), reused 62 (delta 0), pack-reused 0
Receiving objects: 100% (128/128), 113.85 KiB | 0 bytes/s, done.
Resolving deltas: 100% (1/1), done.
Checking connectivity... done.

Error: Directory 'doc' not found
siffiejoe@Merkur:~/src/lua/u [SVN*] :( 

The one on GitHub works fine.

A lot of linters (jshint, jscs, scss-lint, coffeelint) that allow configuration via a .rc file look for it in the folder of the file being linted, but will also look in all parent folders until either a .rc file is found or the root of the filesystem is reached.

I see no reason why luacheck couldn't do the same thing. The performance impact is minimal and has the added benefit of being familiar with the above mentioned linters, which is nice for web projects that use lua either as a backend, or to leverage Redis' scripting functionality.

In my opinion, the decision of looking for .luacheckrc in the current working directory is questionable at best; the whole point of the config file is to be coupled with the source tree (for example to add per-project globals), whereas if using absolute paths, you'll get different behavior depending on where exactly you're running luacheck from. I fail to see a use case when this is what you want.

This function will never be reported as unused, because it is referring to itself:

local function foo()
    return foo
end

This occurs commonly in case of recursion, so it could be worth to ignore these self-references when counting usages.

Would be great to have a --suppress-colors (or --no-color or something) for terminal output (this would be helpful for showing output inside sublime text)

Would it be possible to provide three different rockspecs per luacheck version (e.g. luacheck-0.10.0-51.rockspec, ..., luacheck-0.10.0-53.rockspec) which depend on a specific Lua version each ("lua ~> 5.x" in the dependencies table) and install a versioned luacheck command (e.g. luacheck-5.1) in addition to/instead of the general luacheck script? This way one could install and run luacheck for different Lua versions side by side.

I have a bunch of directories several levels deep that contain, among others, a bunch of Lua files but these files have a .map extension instead of .lua.
I can't seem to invoke luacheck to find and check these files. I tried a command line like luacheck . --include-files **/*.map but it doesn't find any file.

I had a look at the code in main.lua, more specifically expand_files(). When I specify a directory on the command line as a starting point (. in my example) then fs.is_dir() will be true and it will use fs.extract_files(file, "%.lua$") to find all filenames to check. I.e. only files ending in .lua will be found. The patterns given in --exclude-files and --include-files are only checked afterwards, in add().

Is my use case indeed unsupported right now? Any suggestion?

Hi,

The following Lua file 'foo.lua':

local string_format = string.format
local io_stderr = io.stderr

local bar 
if true then
    bar = function (a, b)
        io_stderr:write(string_format("hello luacheck\n"))
    end 
end

will generate the result:

$ luacheck -av foo.lua
Checking foo.lua                                  Failure
    foo.lua:1:7: unused variable string_format
    foo.lua:2:7: unused variable io_stderr
Total: 2 warnings / 0 errors in 1 file

Is it an expected behavior or a bug? Thanks.

With the following file

local f = function(x)
  if not x.y then
    print(x)
  else
    f(x.y)
  end
end

local t = {}
t.y = "test"

f(t)

luacheck returns 1 error for line 5

tmp.lua:5:5: accessing undefined variable f

DId I miss something, or is this just not supported by luacheck?

At work we had some code that triggered the compilation error, "function at line ___ has more than 60 upvalues". While our testing caught it, I think luacheck could also find and flag these issues as well.

60 is the default defined somewhere and I suppose someone could override it and recompile. If we check for this, we should also have a configuration option that specifies this limit.

In Lua, "_" is only a convention with no inherent special meaning but it's commonly used to signify that we dont care about that variable

for _, data in pairs(db_entries) do
...

However, sometimes having naming that unused variable can provide helpful context. What are your thoughts on a flag which, when enables, ignores unused variables starting with a _. This is common practice in other languages

for _ref_id, data in pairs(db_entries) do
...

the common idiom (since Lua 5.2) _ENV = nil causes the following warning:

setting non-standard global variable _ENV

We discuss the implementation of TAP or JUnit at #19 and it seems I pointed you to the wrong direction regrading JUnit.

This xml will be detected as only one error

<?xml version="1.0" encoding="UTF-8"?>
<testsuite name="Luacheck report" tests="1">
    <testcase name="ngcp/avp.lua" classname="ngcp/avp.lua">
        <failure type="W111" message="ngcp/avp.lua:21:1: setting non-standard global variable 'NGCPAvp'"/>
        <failure type="W111" message="ngcp/avp.lua:24:1: setting non-standard global variable 'NGCPAvp_MT'"/>
        <failure type="W113" message="ngcp/avp.lua:25:15: accessing undefined variable 'NGCPAvp'"/>
        <failure type="W112" message="ngcp/avp.lua:28:14: mutating non-standard global variable 'NGCPAvp'"/>
        <failure type="W212" message="ngcp/avp.lua:28:25: unused argument 'self'"/>
        <failure type="W112" message="ngcp/avp.lua:30:9: mutating non-standard global variable 'NGCPAvp_MT'"/>
        <failure type="W113" message="ngcp/avp.lua:34:24: accessing undefined variable 'sr'"/>
        <failure type="W211" message="ngcp/avp.lua:36:23: unused variable 'i'"/>
        <failure type="W211" message="ngcp/avp.lua:36:26: unused variable 'v'"/>
        <failure type="W421" message="ngcp/avp.lua:37:21: shadowing definition of variable 'i' on line 36"/>
        <failure type="W113" message="ngcp/avp.lua:41:17: accessing undefined variable 'sr'"/>
        <failure type="W113" message="ngcp/avp.lua:43:17: accessing undefined variable 'sr'"/>
        <failure type="W113" message="ngcp/avp.lua:49:20: accessing undefined variable 'sr'"/>
        <failure type="W112" message="ngcp/avp.lua:51:9: mutating non-standard global variable 'NGCPAvp_MT'"/>
        <failure type="W113" message="ngcp/avp.lua:52:27: accessing undefined variable 'sr'"/>
        <failure type="W113" message="ngcp/avp.lua:55:33: accessing undefined variable 'NGCPAvp_MT'"/>
        <failure type="W112" message="ngcp/avp.lua:58:14: mutating non-standard global variable 'NGCPAvp'"/>
        <failure type="W113" message="ngcp/avp.lua:62:9: accessing undefined variable 'sr'"/>
        <failure type="W112" message="ngcp/avp.lua:65:14: mutating non-standard global variable 'NGCPAvp'"/>
        <failure type="W113" message="ngcp/avp.lua:69:9: accessing undefined variable 'sr'"/>
    </testcase>
</testsuite>

I think it can't be more than one inside

With this result you will never be able of know if the errors are decreasing or increasing just in the case of none errors versus any amount of errors.

So, I apologize for my initial assumption that one error per file should be OK

Currently column position are reported in bytes.

Eg:

local hand = {['♥']={}}
print(hand['♥'][i])

luacheck --ranges test.lua will reports follow warning:

spec/Hand_spec.lua:2:19-19: accessing undefined variable i

In atom with linter-luacheck displays:

The problems is ♥ has 3 bytes in utf8 which caused 2 character offset in Atom.

Is it possible to include an option like --characters in luacheck to report column position in characters rather than bytes? Maybe a related options such as --encoding is needed (or --characters default treat input as utf8 is enough).

This is such a small and trivial request, and also one that is mostly about opinion:

renaming .\luacheck.lua to .\luacheck/init.lua makes manual installation (especially dealing with deployment systems that make recursion somewhat painful... ie nuget/coapp) easier.

Feel free to ignore this, but I thought I'd throw it out. Thanks!

Hey,

I've just written (technically forked then rewritten, but w/e) a gulp plugin for luacheck. The package is available on npm so installing it should be a piece of cake. It depends on the luacheck bindings for Node.JS, that I've also written and published on npm. The separation is mostly there to allow for easier luacheck integration with other Node.JS build systems (such as Grunt)

While there hasn't been a lot of testing involved, I intend to maintain both packages in the foreseeable future, as I'm an avid Redis user and need them myself. Can you link to my two projects in luacheck's README?

Since this is technically an issue, is there any way to make luacheck read from stdin instead of a file?

• Add a way to describe structure of global tables, supporting read-only fields. Describe standard global tables (string, math, etc).
• Detect accessing fields not listed in description. Fields of locals likely to share value with globals (e.g. local table = table, local table = _G.table, local table = require "table") should be considered as well.

GLOB patterns for including/excluding files

It would be nice if the user would be able to specify glob like include and exclude patterns for files which shall be checked (on the command line and the config file).

Reasoning

Some workspaces might define a .luacheckrc in the root directory. Usualy luacheck is used from there

 user@host: ~/workspace$ luacheck . 

The problem is that the workspace also contains a tests directory and a directory for third party modules whose analysis aren't relevant. Even if the warnings of those files are suppressed/ignored they still add quite some noise (irrelevant data) to the output.

Checking tests/_test1.lua          OK
Checking tests/_tests_dir_includes.lua            OK
Checking libs/cool_module1.lua            OK
Checking libs/cool_module2.lua            OK
Checking an_actually_important_file.lua            OK
...

Can we have options to print token offset in addtion to line and colum?

That would help a lot for linter-luacheck.
currently linter-luacheck parse the output and calculte the offset.

In short, how would I need to write my .luacheckrc if I wanted both the lua53 and busted options to be set for std by default?

LuaJIT has a list of functions that would preclude the JIT from compiling down to bytecode. I'd like a warning, perhaps off by default, that can flag when such a function is used.

I tried installing this on Ubuntu 14.04 and I get a problem with the 30log version. Separately getting 30log didn't help. These are the commands I ran:

sudo apt-get install luarocks
sudo luarocks install luacheck

Error: Failed installing dependency: http://luarocks.org/repositories/rocks/argparse-0.3.0-1.src.rock - Parse error processing dependency '30log >= 0.9.1'

Then I tried:

sudo luarocks install 30log

Installing http://luarocks.org/repositories/rocks/30log-0.9.1-1.src.rock...
Using http://luarocks.org/repositories/rocks/30log-0.9.1-1.src.rock... switching to 'build' mode
Archive: /tmp/luarocks_luarocks-rock-30log-0.9.1-1-3286/30log-0.9.1-1.src.rock
inflating: 30log-0.9.1-1.rockspec
inflating: 30log-0.9.1-1.tar.gz
Updating manifest for /usr/local/lib/luarocks/rocks

30log 0.9.1-1 is now built and installed in /usr/local/ (license: MIT http://www.opensource.org/licenses/mit-license.php)

sudo luarocks install luacheck

Error: Failed installing dependency: http://luarocks.org/repositories/rocks/argparse-0.3.0-1.src.rock - Parse error processing dependency '30log >= 0.9.1'

Full log:

Installing http://luarocks.org/repositories/rocks/luacheck-0.5.0-1.src.rock...
Using http://luarocks.org/repositories/rocks/luacheck-0.5.0-1.src.rock... switching to 'build' mode
Archive: /tmp/luarocks_luarocks-rock-luacheck-0.5.0-1-5392/luacheck-0.5.0-1.src.rock
inflating: luacheck-0.5.0-1.rockspec
creating: luacheck/
creating: luacheck/doc/
extracting: luacheck/doc/objects.inv
creating: luacheck/doc/_static/
extracting: luacheck/doc/_static/comment.png
inflating: luacheck/doc/_static/sidebar.js
inflating: luacheck/doc/_static/up.png
inflating: luacheck/doc/_static/default.css
inflating: luacheck/doc/_static/ajax-loader.gif
extracting: luacheck/doc/_static/comment-bright.png
inflating: luacheck/doc/_static/doctools.js
inflating: luacheck/doc/_static/searchtools.js
inflating: luacheck/doc/_static/minus.png
inflating: luacheck/doc/_static/up-pressed.png
inflating: luacheck/doc/_static/jquery.js
inflating: luacheck/doc/_static/plus.png
creating: luacheck/doc/_static/fonts/
inflating: luacheck/doc/_static/fonts/fontawesome-webfont.svg
inflating: luacheck/doc/_static/fonts/fontawesome-webfont.eot
inflating: luacheck/doc/_static/fonts/fontawesome-webfont.ttf
inflating: luacheck/doc/_static/fonts/fontawesome-webfont.woff
inflating: luacheck/doc/_static/pygments.css
inflating: luacheck/doc/_static/down.png
inflating: luacheck/doc/_static/websupport.js
inflating: luacheck/doc/_static/down-pressed.png
inflating: luacheck/doc/_static/underscore.js
inflating: luacheck/doc/_static/basic.css
creating: luacheck/doc/_static/js/
inflating: luacheck/doc/_static/js/theme.js
creating: luacheck/doc/_static/css/
inflating: luacheck/doc/_static/css/badge_only.css
inflating: luacheck/doc/_static/css/theme.css
extracting: luacheck/doc/_static/comment-close.png
extracting: luacheck/doc/_static/file.png
inflating: luacheck/doc/config.html
inflating: luacheck/doc/cli.html
inflating: luacheck/doc/genindex.html
inflating: luacheck/doc/searchindex.js
inflating: luacheck/doc/warnings.html
inflating: luacheck/doc/index.html
creating: luacheck/doc/_sources/
inflating: luacheck/doc/_sources/config.txt
inflating: luacheck/doc/_sources/index.txt
inflating: luacheck/doc/_sources/module.txt
inflating: luacheck/doc/_sources/cli.txt
inflating: luacheck/doc/_sources/warnings.txt
inflating: luacheck/doc/module.html
inflating: luacheck/doc/search.html
creating: luacheck/spec/
inflating: luacheck/spec/format_spec.lua
inflating: luacheck/spec/config_spec.lua
inflating: luacheck/spec/scan_spec.lua
inflating: luacheck/spec/expand_rockspec_spec.lua
creating: luacheck/spec/folder/
extracting: luacheck/spec/folder/config
extracting: luacheck/spec/folder/bad_config
extracting: luacheck/spec/folder/bad_rockspec
extracting: luacheck/spec/folder/foo
extracting: luacheck/spec/folder/env_config
inflating: luacheck/spec/folder/rockspec
creating: luacheck/spec/folder/folder2/
extracting: luacheck/spec/folder/folder2/garbage
creating: luacheck/spec/folder/folder1/
extracting: luacheck/spec/folder/folder1/fail
extracting: luacheck/spec/folder/folder1/another
extracting: luacheck/spec/folder/folder1/file
inflating: luacheck/spec/options_spec.lua
inflating: luacheck/spec/cli_spec.lua
inflating: luacheck/spec/luacheck_spec.lua
creating: luacheck/spec/configs/
inflating: luacheck/spec/configs/global_config.luacheckrc
inflating: luacheck/spec/configs/bad_config.luacheckrc
inflating: luacheck/spec/configs/override_config.luacheckrc
extracting: luacheck/spec/configs/limit_config.luacheckrc
creating: luacheck/spec/samples/
inflating: luacheck/spec/samples/good_code.lua
extracting: luacheck/spec/samples/globals.lua
extracting: luacheck/spec/samples/defined.lua
extracting: luacheck/spec/samples/defined2.lua
inflating: luacheck/spec/samples/sample.rockspec
extracting: luacheck/spec/samples/bad.rockspec
inflating: luacheck/spec/samples/defined3.lua
inflating: luacheck/spec/samples/compat.lua
extracting: luacheck/spec/samples/empty.lua
inflating: luacheck/spec/samples/bad_code.lua
extracting: luacheck/spec/samples/python_code.lua
inflating: luacheck/spec/samples/unused_code.lua
inflating: luacheck/spec/samples/argparse.lua
inflating: luacheck/spec/filter_spec.lua
inflating: luacheck/spec/check_spec.lua
inflating: luacheck/spec/utils_spec.lua
inflating: luacheck/LICENSE
inflating: luacheck/.travis_setup.sh
inflating: luacheck/.travis.yml
inflating: luacheck/README.md
creating: luacheck/src/
creating: luacheck/src/luacheck/
inflating: luacheck/src/luacheck/scan.lua
inflating: luacheck/src/luacheck/utils.lua
inflating: luacheck/src/luacheck/check.lua
inflating: luacheck/src/luacheck/options.lua
inflating: luacheck/src/luacheck/format.lua
inflating: luacheck/src/luacheck/filter.lua
inflating: luacheck/src/luacheck/expand_rockspec.lua
inflating: luacheck/src/luacheck/stds.lua
inflating: luacheck/src/luacheck.lua
creating: luacheck/bin/
inflating: luacheck/bin/luacheck.lua
creating: luacheck/docsrc/
inflating: luacheck/docsrc/conf.py
inflating: luacheck/docsrc/index.rst
inflating: luacheck/docsrc/module.rst
inflating: luacheck/docsrc/cli.rst
inflating: luacheck/docsrc/Makefile
inflating: luacheck/docsrc/config.rst
inflating: luacheck/docsrc/warnings.rst
inflating: luacheck/docsrc/make.bat
inflating: luacheck/.luacheckrc
creating: luacheck/rockspecs/
inflating: luacheck/rockspecs/luacheck-0.3.0-1.rockspec
inflating: luacheck/rockspecs/luacheck-scm-4.rockspec
inflating: luacheck/rockspecs/luacheck-0.1.0-1.rockspec
inflating: luacheck/rockspecs/luacheck-scm-1.rockspec
inflating: luacheck/rockspecs/luacheck-0.4.0-1.rockspec
inflating: luacheck/rockspecs/luacheck-0.4.1-1.rockspec
inflating: luacheck/rockspecs/luacheck-0.5.0-1.rockspec
inflating: luacheck/rockspecs/luacheck-scm-5.rockspec
inflating: luacheck/rockspecs/luacheck-scm-2.rockspec
inflating: luacheck/rockspecs/luacheck-0.2.0-1.rockspec
inflating: luacheck/rockspecs/luacheck-scm-3.rockspec

Missing dependencies for luacheck:
argparse >= 0.3.0
ansicolors >= 1.0-1
luafilesystem >= 1.6.2

Using http://luarocks.org/repositories/rocks/argparse-0.3.0-1.src.rock... switching to 'build' mode
Archive: /tmp/luarocks_luarocks-rock-argparse-0.3.0-1-100/argparse-0.3.0-1.src.rock
inflating: argparse-0.3.0-1.rockspec
creating: argparse/
creating: argparse/doc/
creating: argparse/doc/images/
inflating: argparse/doc/images/bg_hr.png
inflating: argparse/doc/images/blacktocat.png
inflating: argparse/doc/index.html
creating: argparse/doc/stylesheets/
inflating: argparse/doc/stylesheets/pygment_trac.css
inflating: argparse/doc/stylesheets/stylesheet.css
creating: argparse/spec/
inflating: argparse/spec/actions_spec.lua
inflating: argparse/spec/commands_spec.lua
inflating: argparse/spec/help_spec.lua
inflating: argparse/spec/default_spec.lua
inflating: argparse/spec/options_spec.lua
inflating: argparse/spec/arguments_spec.lua
inflating: argparse/spec/mutex_spec.lua
inflating: argparse/spec/pparse_spec.lua
inflating: argparse/spec/convert_spec.lua
inflating: argparse/spec/tip_spec.lua
inflating: argparse/spec/usage_spec.lua
inflating: argparse/spec/script
inflating: argparse/spec/integrity_spec.lua
inflating: argparse/LICENSE
inflating: argparse/.travis_setup.sh
inflating: argparse/.travis.yml
inflating: argparse/README.md
creating: argparse/src/
inflating: argparse/src/argparse.lua
creating: argparse/rockspecs/
inflating: argparse/rockspecs/argparse-0.2.0-1.rockspec
inflating: argparse/rockspecs/argparse-0.1.0-1.rockspec
inflating: argparse/rockspecs/argparse-0.3.0-1.rockspec
inflating: argparse/rockspecs/argparse-scm-1.rockspec

Error: Failed installing dependency: http://luarocks.org/repositories/rocks/argparse-0.3.0-1.src.rock - Parse error processing dependency '30log >= 0.9.1'

It worked before, not sure how it broke now. Uninstalled and reinstalled the rock to no effect.

$ luacheck
/usr/bin/lua: /usr/local/share/lua/5.1/luacheck/version.lua:7: attempt to index local 'luacheck' (a function value)
stack traceback:
    /usr/local/share/lua/5.1/luacheck/version.lua:7: in main chunk
    [C]: in function 'require'
    /usr/local/share/lua/5.1/luacheck/main.lua:9: in main chunk
    [C]: in function 'require'
    ...al/lib/luarocks/rocks/luacheck/0.14.0-1/bin/luacheck:2: in main chunk
    [C]: ?

It's a bit strange that luacheck.lua returns luacheck as a function and version.lua expects it to be a table.

Hello Peter,

You have a nice little tool here, and I think you should advertise it more.

I was using luacheck in Sublime Text 3 via SublimeLinter ( https://sublime.wbond.net/packages/SublimeLinter-luacheck ) and everything worked well. I think it's the best linter around, but I guess not many people heard about it yet.

I've switched from Sublime Text to Vim, and there was no out-of-the-box integration for luacheck. So I wrote one for Syntastic ( https://github.com/scrooloose/syntastic/ ), a popular Vim plugin, and sent a pull request ( vim-syntastic/syntastic#1271 ). It depends on the pull request I sent you 😁

My suggestion is that you keep a list of editors that have integrated luacheck, with their respective plugins (SublimeLinter for Sublime Text, Syntastic for Vim) to show that luacheck really works, and exemplify how it can be integrated. Right now it's hard to tell it apart from the various other options that don't work. I can provide you some screenshots from Sublime and Vim if you want.

Cheers

See LuaJIT/LuaJIT#193 (comment)