Usage of '...' outside a vararg function is not throwing an error

[berbun]

For example:
x=function()print(...)end x()
function y()print(...)end y()
_G['z']=function()print(...)end z()

The above are parsed "correctly" by luaparse, however they are illegal at runtime.

cannot use '...' outside a vararg function near '...'

The following is valid:
print(...) -- in the root scope, probably to obtain arguments on command-line

I think this behaviour is documented.
Would be hard to fix ? (not sure)

[fstirlitz]

This is actually a parse-time error; were it a run-time error, I would probably reject this report as invalid.

The only documented way to obtain command-line arguments in Lua is via the arg table (§6 in the 5.1 manual, §7 in 5.2 and in 5.3). The behaviour of ... at the top-level chunk seems to be a side effect of how load was implemented in 5.1; it simply makes all chunks behave like vararg functions, so that you can pass arguments to them (unlike Lua 5.0, in which arguments were ignored), e.g.:

assert(load([[
  local a, b, c = ...
  print(a) -- prints 1
  print(b) -- prints 2
  print(c) -- prints 3
]]))(1, 2, 3)

lua_load likewise treats the chunk like a vararg function body (and pushes a vararg function on the stack if it succeeds), but the stand-alone interpreter doesn't pass any arguments to it, so the ... tuple is empty.

So this seems to be an obscure feature, but with potentially valid use. In a later version I may introduce a warning lint against it (that is, when I introduce warning lints in the first place).

[berbun]

In a later version I may introduce a warning lint against it (that is, when I introduce warning lints in the first place).

May I suggest to make a separate project/repository for linter, and use luaparse as a (git) submodule.
So, they could work independently from each other, this way luaparse could opt-in and still be able to use linter functionality if needed (with module/interface if linter is available/installed).
Keep things neat and organized! 😉

[fstirlitz]

Well, it's a bit of a gray area what should be considered a mere lint and what should be a compile-time error anyway. On one hand you have programming languages with sophisticated type systems where even the slightest possibility of a logic error causes the program to be rejected at compile time. On the other, you have bash and TeX, which are so dynamic that they don't even have a separate ‘compile time’ in the first place. (And for this reason they’re a nightmare to program anything nontrivial in, even more than JS.) I can very well imagine an implementation of Lua which doesn't diagnose any coding errors beyond respecting the basic recursive grammar (like gotos pointing to nowhere, or in fact the issue you reported here) until the very last moment at run time. As far as I am concerned, it would be perfectly compliant to the language specification, if somewhat silly.

But if you’re wondering, the design I have in mind right now would be to remake luaparse into something vaguely event-driven, where lint plugins could seamlessly listen to specific events and track their own metadata independently of each other. That should make it easy to spin off the various lints into independent projects if so desired.

[fstirlitz]

Fixed in f3354f3.