[ANN] Luacheck 0.19.0

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ANN] Luacheck 0.19.0

Peter Melnichenko-2
Hi!

I've released Luacheck 0.19.0. Luacheck is a linter for Lua,
detecting accidental globals, unused variables and values,
unreachable code, etc., see https://github.com/mpeterv/luacheck.

To install it with LuaRocks, run `luarocks install luacheck`.

Breaking changes:

* New format for defining standard sets of globals that can
  describe all allowed fields of each global.

New features and improvements:

* Luacheck can now detect mutations and accesses of specific fields
  within globals. Standard global definitions have been updated
  to provide precise lists of allowed fields. This also
  works through local aliases (e.g. `local t = table; t.upsert()`
  produces a warning, but `local t = table; t.insert()` does not).
* Default set of allowed globals is now equal to globals normally
  provided by version of Lua used to run Luacheck, instead of
  all globals set in the interpreter while it runs Luacheck.
* All options that operate on lists of global names can now use
  field names as well. E.g. `--not-globals string.len` undefines
  standard field `string.len`. Additionally, config options
  `globals`, `new_globals`, `read_globals`, `new_read_globals`
  can use a table-based format to define trees of allowed fields.
* Lines that are longer than some maximum length are now reported.
  Default limit is 120. Limit can be changed using `max_line_length`
  option.
* Warnings related to trailing whitespace in comments
  and inside string literals now use separate warning codes.
* Luacheck no longer reports a crash with a long traceback when
  interrupted, instead it simply exits with an error message.

Fixes:

* Fixed inconsistent indentation (TAB after space) not being detected
  on lines with trailing whitespace.

Cheers,

Peter

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Peter Aronoff
Peter Melnichenko <[hidden email]> wrote:
> I've released Luacheck 0.19.0.

Thanks!

A quick question, and I apologize because I don’t recall if this was an
issue before or it’s new. Like a lot of people, I now use this in modules
that require unpack:

        local unpack = unpack or table.unpack

That, however, yields this warning from luacheck:

        src/tapered.lua:9:16: accessing undefined variable unpack

I get what’s happening here, and I can simply choose to ignore this
warning, but I wonder if people have any thoughts about how else to handle
a cross-lua module that uses unpack.

Thanks, Peter
--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
    Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Francisco Olarte
On Fri, Mar 3, 2017 at 7:01 PM, Peter Aronoff <[hidden email]> wrote:

> A quick question, and I apologize because I don’t recall if this was an
> issue before or it’s new. Like a lot of people, I now use this in modules
> that require unpack:
>
>         local unpack = unpack or table.unpack
>
> That, however, yields this warning from luacheck:
>
>         src/tapered.lua:9:16: accessing undefined variable unpack
>
> I get what’s happening here, and I can simply choose to ignore this
> warning, but I wonder if people have any thoughts about how else to handle
> a cross-lua module that uses unpack.

luacheck --std max or --read-globals unpack ?

Francisco Olarte.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Xavier Wang
In reply to this post by Peter Aronoff

Peter Aronoff <[hidden email]>于2017年3月4日 周六上午2:01写道:
Peter Melnichenko <[hidden email]> wrote:
> I've released Luacheck 0.19.0.

Thanks!

A quick question, and I apologize because I don’t recall if this was an
issue before or it’s new. Like a lot of people, I now use this in modules
that require unpack:

        local unpack = unpack or table.unpack

That, however, yields this warning from luacheck:

        src/tapered.lua:9:16: accessing undefined variable unpack

I get what’s happening here, and I can simply choose to ignore this
warning, but I wonder if people have any thoughts about how else to handle
a cross-lua module that uses unpack.

Thanks, Peter
--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
    Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

I used to write it as 
local unpack = _G.unpack or table.unpack

But it maybe can not work in this new version...
--
regards,
Xavier Wang.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Dirk Laurie-2
In reply to this post by Peter Aronoff
2017-03-03 20:01 GMT+02:00 Peter Aronoff <[hidden email]>:

> Peter Melnichenko <[hidden email]> wrote:
>> I've released Luacheck 0.19.0.
>
> Thanks!
>
> A quick question, and I apologize because I don’t recall if this was an
> issue before or it’s new. Like a lot of people, I now use this in modules
> that require unpack:
>
>         local unpack = unpack or table.unpack
>
> That, however, yields this warning from luacheck:
>
>         src/tapered.lua:9:16: accessing undefined variable unpack
>
> I get what’s happening here, and I can simply choose to ignore this
> warning, but I wonder if people have any thoughts about how else to handle
> a cross-lua module that uses unpack.
>
> Thanks, Peter
> --
> We have not been faced with the need to satisfy someone else's
> requirements, and for this freedom we are grateful.
>     Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

You could try

    local unpack = table.unpack or unpack

Speaking as someone who does not feel the need to satisfy luacheck's
requirements, I can't test whether that will do the trick.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Peter Aronoff
Dirk Laurie <[hidden email]> wrote:
> You could try
>
>     local unpack = table.unpack or unpack
>
> Speaking as someone who does not feel the need to satisfy luacheck's
> requirements, I can't test whether that will do the trick.

I suspect it would silence the warning for Lua 5.3, but create warnings for
lower versions of Lua (which would have nothing defined for table.unpack).

I’m not so much concerned with the one warning as I am the general question
of how other people do this require. The idea of _G.unpack makes good sense
to me, and it also silences the warning.

Thanks all, Peter
--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
    Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Peter Melnichenko-2
In reply to this post by Peter Aronoff
On Fri, Mar 3, 2017 at 9:01 PM, Peter Aronoff <[hidden email]> wrote:

> Peter Melnichenko <[hidden email]> wrote:
>> I've released Luacheck 0.19.0.
>
> Thanks!
>
> A quick question, and I apologize because I don’t recall if this was an
> issue before or it’s new. Like a lot of people, I now use this in modules
> that require unpack:
>
>         local unpack = unpack or table.unpack
>
> That, however, yields this warning from luacheck:
>
>         src/tapered.lua:9:16: accessing undefined variable unpack
>
> I get what’s happening here, and I can simply choose to ignore this
> warning, but I wonder if people have any thoughts about how else to handle
> a cross-lua module that uses unpack.
>
> Thanks, Peter
> --
> We have not been faced with the need to satisfy someone else's
> requirements, and for this freedom we are grateful.
>     Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System
>

The best solution is to allow non-portable globals for that line only:

    local unpack = unpack or table.unpack -- luacheck: compat

-- Peter

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Peter Aronoff
Peter Melnichenko <[hidden email]> wrote:
> The best solution is to allow non-portable globals for that line only:
>
>     local unpack = unpack or table.unpack -- luacheck: compat
>
> -- Peter

Thanks for this. I’ll look more into the options to tell luacheck what to
do for specific lines in this way.

That said, I now wonder about something more general. When people write in
Lua `local x = y or z`, that’s often an idiom for cases where y is likely
to be nil. Or, at least, where y can be nil, but the program should
continue without trouble by assigning z to x instead of y. In my mind, it
isn’t clear whether this *should* trigger a warning, since presumably the
programmer puts that “or z” in there to address the danger of y being nil.

Thoughts?

Thanks, Peter
--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
    Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Peter Melnichenko-2
On Fri, Mar 3, 2017 at 10:10 PM, Peter Aronoff <[hidden email]> wrote:

> That said, I now wonder about something more general. When people write in
> Lua `local x = y or z`, that’s often an idiom for cases where y is likely
> to be nil. Or, at least, where y can be nil, but the program should
> continue without trouble by assigning z to x instead of y. In my mind, it
> isn’t clear whether this *should* trigger a warning, since presumably the
> programmer puts that “or z” in there to address the danger of y being nil.
>
> Thoughts?
>
> Thanks, Peter
> --
> We have not been faced with the need to satisfy someone else's
> requirements, and for this freedom we are grateful.
>     Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System
>

Yes, it would be more convenient if this idiom was recognized. But there
should still be a warning if the global variable is definitely incorrect, e.g.
`local load = loadstringgg or load`. So that means that Luacheck would
need a new class of defined globals that can only be accessed through
this idiom. It already distinguishes read-only and settable globals
so it shouldn't be difficult to implement this.

Some minor problems: strange things like
`local load = loadstring or table.unpack` will be allowed, while
variations of the idiom like
`local unpack = unpack ~= nil and unpack or table.unpack` won't.

-- Peter

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Dirk Laurie-2
2017-03-03 23:11 GMT+02:00 Peter Melnichenko <[hidden email]>:

> Yes, it would be more convenient if this idiom was recognized. But there
> should still be a warning if the global variable is definitely incorrect, e.g.
> `local load = loadstringgg or load`. So that means that Luacheck would
> need a new class of defined globals that can only be accessed through
> this idiom. It already distinguishes read-only and settable globals
> so it shouldn't be difficult to implement this.
>
> Some minor problems: strange things like
> `local load = loadstring or table.unpack` will be allowed, while
> variations of the idiom like
> `local unpack = unpack ~= nil and unpack or table.unpack` won't.

What is the main reason for using Luacheck?

(a) A debugging tool.
(b) Enforcing a certain style of coding.
(c) Advising a programmer on things in his program that
might make trouble one day.

Unless you use it for (b), I would not be concerned about the
occasional extra warning in situations where any human can
see it is OK. Turing has already taught us that we can't use
a program to test correctness of a program. Why clutter
Luacheck with exceptional cases?

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Martin
On 03/03/2017 08:26 PM, Dirk Laurie wrote:
> What is the main reason for using Luacheck?
>
> (a) A debugging tool.
> (b) Enforcing a certain style of coding.
> (c) Advising a programmer on things in his program that
> might make trouble one day.
>

All use cases I encountered in production work was (b).

This annoyed me as I think programmer should code any style he/she
wants. Code further may be arbitrarily post-processed according
corporation/company/another_person wishes. So I've implemented
code formatter (which currently strips all comments, so it is
still unsuitable for production use).

> Unless you use it for (b), I would not be concerned about the
> occasional extra warning in situations where any human can
> see it is OK.

Having a tool which can detect some (simple) cases of referencing
global variable is not bad. I appreciate luacheck for this ability.

> Turing has already taught us that we can't use
> a program to test correctness of a program. Why clutter
> Luacheck with exceptional cases?

Especially in dynamic languages as Lua. Where functions can
generate functions and arbitrary string can be converted to
function via load().

I believe only way to get result of program is execute it.
(And hope Turing believed/proved this too.)

> (c) Advising a programmer on things in his program that
> might make trouble one day.

You can add a hook to reference to global table but this have no
sense for code you trust (but useful for code stalking/research/hacking).

(Personally I prefer to prefix all queries to non-standard
global table values with "_G.".)

There are many implementations of idea to make language more
restrictive, from creating strict-type language, through code and
byte-code preanalysis, to sandboxes and run-time tracking.
Probably this is due new programmers which get from Lua more power
they can handle.

-- Martin

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Sean Conner
It was thus said that the Great Martin once stated:

> On 03/03/2017 08:26 PM, Dirk Laurie wrote:
> > What is the main reason for using Luacheck?
> >
> > (a) A debugging tool.
> > (b) Enforcing a certain style of coding.
> > (c) Advising a programmer on things in his program that
> > might make trouble one day.
> >
>
> All use cases I encountered in production work was (b).

  And mine are (c).  luacheck helped fine some potential bugs in the code at
work (mostly inadvertent globals but some mistakes on shadowing previous
variables).

> > Turing has already taught us that we can't use
> > a program to test correctness of a program. Why clutter
> > Luacheck with exceptional cases?
>
> Especially in dynamic languages as Lua. Where functions can
> generate functions and arbitrary string can be converted to
> function via load().
>
> I believe only way to get result of program is execute it.
> (And hope Turing believed/proved this too.)

  While it's true in general that Turing proved that there are some things a
program can't determine from source code alone, that shouldn't preclude the
checks we *can* do to minimize bugs.

  -spc (And those checks that luacheck does that I disagree with I disable ... )


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Peter Melnichenko-2
In reply to this post by Dirk Laurie-2
On Sat, Mar 4, 2017 at 7:26 AM, Dirk Laurie <[hidden email]> wrote:

> What is the main reason for using Luacheck?
>
> (a) A debugging tool.
> (b) Enforcing a certain style of coding.
> (c) Advising a programmer on things in his program that
> might make trouble one day.
>
> Unless you use it for (b), I would not be concerned about the
> occasional extra warning in situations where any human can
> see it is OK. Turing has already taught us that we can't use
> a program to test correctness of a program. Why clutter
> Luacheck with exceptional cases?
>

It's mostly c) but it is sometimes difficult to distinguish these cases.
E.g. in my opinion shadowing a local with a new one with the same name
can be a source of bugs, but I've seen people consider warnings
about this annoying and stylistic. I try to make the warnings
clear-cut and provide options to ignore some of them according
to alternative preferences. It seems like overkill in this
particular case though.

-- Peter

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Peter Aronoff
In reply to this post by Martin
Martin <[hidden email]> wrote:
> (Personally I prefer to prefix all queries to non-standard
> global table values with "_G.".)

This may be a tangent, but what do you mean by saying you “prefer to prefix
all queries to non-standard global table values with "_G"”? What would
a “non-standard global table value” even be? Isn’t the whole point of _G
that the values that are (already) there are standard?

P
--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
    Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Peter Aronoff
In reply to this post by Dirk Laurie-2
Dirk Laurie <[hidden email]> wrote:

> What is the main reason for using Luacheck?
>
> (a) A debugging tool.
> (b) Enforcing a certain style of coding.
> (c) Advising a programmer on things in his program that
> might make trouble one day.
>
> Unless you use it for (b), I would not be concerned about the
> occasional extra warning in situations where any human can
> see it is OK. Turing has already taught us that we can't use
> a program to test correctness of a program. Why clutter
> Luacheck with exceptional cases?

This seems reasonable enough, and my point wasn’t to force luacheck to do
enormous amounts of work. But I still think that a linter for language
X shouldn’t (in general) warn against using standard idioms in language X.

P
--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
    Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Dirk Laurie-2
2017-03-04 14:45 GMT+02:00 Peter Aronoff <[hidden email]>:

> Dirk Laurie <[hidden email]> wrote:
>> What is the main reason for using Luacheck?
>>
>> (a) A debugging tool.
>> (b) Enforcing a certain style of coding.
>> (c) Advising a programmer on things in his program that
>> might make trouble one day.
>>
>> Unless you use it for (b), I would not be concerned about the
>> occasional extra warning in situations where any human can
>> see it is OK. Turing has already taught us that we can't use
>> a program to test correctness of a program. Why clutter
>> Luacheck with exceptional cases?
>
> This seems reasonable enough, and my point wasn’t to force luacheck to do
> enormous amounts of work. But I still think that a linter for language
> X shouldn’t (in general) warn against using standard idioms in language X.

Fair enough ... but in that case one should in general not flag the idiom.
I.e. `undefined_global or workaround` should pass whenever `workaround`
passes, whether the global name is present in some known version of Lua
or not.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Martin
In reply to this post by Peter Aronoff
On 03/04/2017 04:43 AM, Peter Aronoff wrote:
> Martin <[hidden email]> wrote:
>> (Personally I prefer to prefix all queries to non-standard
>> global table values with "_G.".)
>
> This may be a tangent, but what do you mean by saying you “prefer to prefix
> all queries to non-standard global table values with "_G"”? What would
> a “non-standard global table value” even be? Isn’t the whole point of _G
> that the values that are (already) there are standard?

I mean when I add something to global table I tend to write
it explicit:

  local my_new_func = function() end
  ...
  _G.new_func = my_new_func

And if I doubts in clarity need I may call it as

  _G.new_func(...)

Surely I don't write

  for k, v in _G.pairs(t) do end

As all values that in _G when you just loaded interpreter
I consider "standard".

-- Martin

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Pierre Chapuis
In reply to this post by Peter Melnichenko-2
I just want to take this occasion to thank you for Luacheck. It is the
one tool that has improved the quality of my Lua code the most.

We introduced Lua at the company I work for last year. We use it as a
scripting language on top of a C core. I was the only employee with
experience with it and I was afraid of the issues that the dynamic
nature of the language could cause, so we enforced clean Luacheck
output on all builds; I think it helps a lot.

We only have about 6000 lines of Lua code so far with four
contributors, but both those figures are going to grow. I cannot know
for sure how well it is going to work, but I know it would have been
a lot harder without Luacheck.

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Marc Balmer
> I just want to take this occasion to thank you for Luacheck. It is the
> one tool that has improved the quality of my Lua code the most.
>
> We introduced Lua at the company I work for last year. We use it as a
> scripting language on top of a C core. I was the only employee with
> experience with it and I was afraid of the issues that the dynamic
> nature of the language could cause, so we enforced clean Luacheck
> output on all builds; I think it helps a lot.
>
> We only have about 6000 lines of Lua code so far with four
> contributors, but both those figures are going to grow. I cannot know
> for sure how well it is going to work, but I know it would have been
> a lot harder without Luacheck.

Here, Lua has improved the code in general.  We used to do 100% in C,
and especially younger talent had its problems with memory management,
pointers etc.

Once we introduced Lua, productivity began to soar.  Lua is a revelation.

We are currently at ~193'000 lines of C code (that includes third party
code like Lua itself), ~ 83'000 lines of Lua code, ~ 40'000 lines of Lua
templates, 128'000 lines of HTML, 40'000 lines of CSS (again, third
party code included), and, of which we are proud the most, exactly 0
lines of perl code.

Time to check that code with Luacheck, I guess.  Tnanks for making it
available.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Luacheck 0.19.0

Hisham
In reply to this post by Pierre Chapuis
On 4 March 2017 at 12:02, Pierre Chapuis <[hidden email]> wrote:
> I just want to take this occasion to thank you for Luacheck. It is the
> one tool that has improved the quality of my Lua code the most.

I was just about to post in this thread for this same reason and it's
nice to see someone already beat me to it. :) So I second Pierre's
words. Luacheck is my favorite Lua tool.

I have it integrated with my text editor, so essentially I only code
Lua using Luacheck nowadays.

-- Hisham

12