unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "Mattias Engdegård" <mattias.engdegard@gmail.com>
Cc: 60830@debbugs.gnu.org, Stefan Kangas <stefankangas@gmail.com>,
	Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors
Date: Sat, 07 Oct 2023 23:02:25 +0200	[thread overview]
Message-ID: <m2ttr2ywm6.fsf@me.com> (raw)
In-Reply-To: <4996E536-72CE-4E6A-9C75-CF7307A82469@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 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.

Good catch!  I have two questions:

(1) How can I specify "this group cannot be '[C]'" in the regexp?
(2) How can I test this scenario in 'compile-tests.el'?

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

I made the relevant groups greedy, but I wonder what difference it
makes.  Is there a way to test the change in 'compile-tests.el'?

> 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?

Good catch!  Fixed.

> Don't keep capture groups that you don't use.

Fixed and TIL about "shy groups".

> 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?

I would understand if we did that for some long-dead compilers but not
for Lua.  I think we need a systematic approach to solve the performance
penalty and false positives.  Arbitrarily disabling languages that are
alive and well, and even supported by Emacs out of the box, such as Lua,
is not a good idea, IMHO.

>> 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.

We still detect the file path/name, which is useful.  That said, Lua
stack frames typically include line numbers.

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

Fixed.

[The current version of the patch is attached below.]

Rudy

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Make-the-Compilation-mode-recognize-Lua-errors.patch --]
[-- Type: text/x-patch, Size: 4980 bytes --]

From 0d2e317efd7f66d5605cd804648d30f7beef6709 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= <salutis@me.com>
Date: Tue, 3 Oct 2023 09:07:40 +0200
Subject: [PATCH] Make the Compilation mode recognize Lua errors

Emacs comes with built-in support for the Lua programming language in
the form of the Lua mode and now also the Lua Tree-sitter mode.  This
patch further improves Lua support in Emacs by making the Compilation
mode recognize Lua errors and stack traces.

Reported as bug#60830.

* etc/compilation.txt (Lua): Add an example of a Lua error message
with a stack trace.

* lisp/progmodes/compile.el (compilation-error-regexp-alist-alist):
Add regexps to aid Lua development, namely the 'lua' regexp that
matches Lua errors and the 'lua-stack' regexp that matches Lua stack
frames.

* test/lisp/progmodes/compile-tests.el (compile-tests--test-regexps-data):
(compile-test-error-regexps): Test the new 'lua' and 'lua-stack'
regexps added to the 'compilation-error-regexp-alist-alist'.
---
 etc/NEWS                             |  5 +++++
 etc/compilation.txt                  | 13 +++++++++++++
 lisp/progmodes/compile.el            |  7 +++++++
 test/lisp/progmodes/compile-tests.el | 19 +++++++++++++++++--
 4 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index 12c2d52a4ab..cf98e8d6f43 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -307,6 +307,11 @@ This is because it partly acts by modifying other rules which may
 occasionally be surprising.  It can be re-enabled by adding 'omake' to
 'compilation-error-regexp-alist'.
 
+*** Lua errors and stack traces are now recognized.
+The compilation mode now recognizes Lua language errors and stack
+traces.  Every Lua error is recognized as a compilation error, and
+every Lua stack frame is recognized as a compilation info.
+
 ** VC
 
 ---
diff --git a/etc/compilation.txt b/etc/compilation.txt
index 5f6ecb09cc2..9a5e3e732c8 100644
--- a/etc/compilation.txt
+++ b/etc/compilation.txt
@@ -344,6 +344,19 @@ In /home/janneke/vc/guile/examples/gud-break.scm:
 1033: 0 [stderr "~a:hello world\n" (# # #)]
 
 
+* Lua
+
+/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 ?
+
+
 * Lucid Compiler, lcc 3.x
 
 symbol: lcc
diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index 9e441dbfcf7..a394f953775 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -362,6 +362,13 @@ compilation-error-regexp-alist-alist
     (ruby-Test::Unit
      "^    [[ ]?\\([^ (].*\\):\\([1-9][0-9]*\\)\\(\\]\\)?:in " 1 2)
 
+    (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 2 nil 0 1)
+
     (gmake
      ;; Set GNU make error messages as INFO level.
      ;; It starts with the name of the make program which is variable,
diff --git a/test/lisp/progmodes/compile-tests.el b/test/lisp/progmodes/compile-tests.el
index d497644c389..3ed41e8afb1 100644
--- a/test/lisp/progmodes/compile-tests.el
+++ b/test/lisp/progmodes/compile-tests.el
@@ -206,6 +206,21 @@ compile-tests--test-regexps-data
      1 0 31 "/usr/include/c++/3.3/backward/iostream.h")
     (gcc-include "                 from test_clt.cc:1:"
      1 nil 1 "test_clt.cc")
+    ;; Lua
+    (lua "lua: database.lua:10: assertion failed!\nstack traceback:\n\t"
+         6 nil 10 "database.lua")
+    (lua "lua 5.4: database 2.lua:10: assertion failed!\nstack traceback:\n\t"
+         10 nil 10 "database 2.lua")
+    (lua "/usr/local/bin/lua: core/database.lua:20: assertion failed!\nstack traceback:\n\t"
+         21 nil 20 "core/database.lua")
+    (lua-stack "	database.lua: in field 'statement'"
+               2 nil nil "database.lua" 0)
+    (lua-stack "	database.lua:10: in field 'statement'"
+               2 nil 10 "database.lua" 0)
+    (lua-stack "	core/database.lua:20: in field 'statement'"
+               2 nil 20 "core/database.lua" 0)
+    (lua-stack "	database 2.lua: in field 'statement'"
+               2 nil nil "database 2.lua" 0)
     ;; gmake
     (gmake "make: *** [Makefile:20: all] Error 2" 12 nil 20 "Makefile" 0)
     (gmake "make[4]: *** [sub/make.mk:19: all] Error 127" 15 nil 19
@@ -507,9 +522,9 @@ compile-test-error-regexps
                    1 15 5 "alpha.c")))
         (compile--test-error-line test))
 
-      (should (eq compilation-num-errors-found 100))
+      (should (eq compilation-num-errors-found 103))
       (should (eq compilation-num-warnings-found 35))
-      (should (eq compilation-num-infos-found 28)))))
+      (should (eq compilation-num-infos-found 32)))))
 
 (ert-deftest compile-test-grep-regexps ()
   "Test the `grep-regexp-alist' regexps.
-- 
2.39.3 (Apple Git-145)


[-- Attachment #3: Type: text/plain, Size: 254 bytes --]

-- 
"It is no paradox to say that in our most theoretical moods we may be
nearest to our most practical applications."
-- Alfred North Whitehead, 1861-1947

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

  parent reply	other threads:[~2023-10-07 21:02 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-15 11:33 bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-13 14:55 ` Stefan Kangas
2023-10-02 12:04   ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-02 18:37     ` Stefan Kangas
2023-10-03  8:12       ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-03  9:37         ` Stefan Kangas
2023-10-03 20:03           ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-05 11:27         ` Mattias Engdegård
2023-10-05 16:21           ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-06 11:38             ` Mattias Engdegård
2023-10-06 13:21               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-06 14:00                 ` Mattias Engdegård
2023-10-06 14:47                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-06 16:20                     ` Mattias Engdegård
2023-10-06 16:49                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-07 11:18                         ` Mattias Engdegård
2023-10-07 15:22                           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-08 10:45                             ` Mattias Engdegård
2023-10-08 14:47                               ` Mattias Engdegård
2023-10-07 21:02               ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-10-08  9:59                 ` Mattias Engdegård
2023-10-12  8:12                   ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-12  8:17                     ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-12 14:32                     ` Mattias Engdegård
2023-12-10 22:53                       ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-10 13:48                         ` Stefan Kangas
2024-01-10 16:37                           ` Mattias Engdegård
2024-01-10 17:09                             ` Stefan Kangas
2024-01-10 17:45                               ` Mattias Engdegård
2023-10-08 15:49                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-12  8:14                   ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2ttr2ywm6.fsf@me.com \
    --to=bug-gnu-emacs@gnu.org \
    --cc=60830@debbugs.gnu.org \
    --cc=mattias.engdegard@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    --cc=salutis@me.com \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).