bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors

[Mattias Engdegård]

5 okt. 2023 kl. 18.21 skrev Rudolf Adamkovič <salutis@me.com>:

> So, I studied 'luaL_traceback' in 'lauxlib.c' in Lua and
> made the regular expression more precise.  No more mis-classification!

That's the spirit!

> /usr/bin/lua: database.lua:31: assertion failed!
> stack traceback:
>       [C]: in function 'assert'
>       database.lua:31: in field 'statement'
>       database.lua:42: in field 'table'
>       database.lua:55: in field 'row'
>       database.lua:63: in field 'value'
>       database.lua:68: in main chunk
>       [C]: in ?

Your rules incorrectly match "[C]" as a file name. This isn't just a matter of 
aesthetics; the user must be able to step through matches without tripping.

As to your implementation:

>     (lua
>      "^[^:\n\t]+: \\([^: \n\t]+\\):\\([0-9]+\\): .*?\nstack traceback:\n\t"
>      1 2 nil 2 1)
>     (lua-stack
>      "^\t\\([^:\n\t]+\\):\\(\\([0-9]+\\):\\)? in "
>      1 3 nil 0 1)

I see no reason for the non-greedy match in the first regexp, do you?

We try to make rules work with Windows file names (or names containing spaces, 
which are also somewhat common on Windows) where relevant and practical. Your 
patterns don't; can you argue that it's not useful for Lua or not possible to 
do so?

Don't keep capture groups that you don't use. (If you use rx then you don't 
have to think about it. If you don't, I'm probably going to translate your 
regexp to rx anyway.)

I'm still erring on having these rules disabled by default because they seem 
very close to unrelated compiler output. Would that be a major inconvenience?

> While on it, I also added support for stack frames with no line
> number, as per Lua source code.

That doesn't result in anything useful as far as I can tell.

>  Lastly, I added a NEWS entry, as well
> as, improved the commit message a bit.

Please include an addition to etc/compilation.txt as well.