From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Rudolf =?UTF-8?Q?Adamkovi=C4=8D?= via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors Date: Sat, 07 Oct 2023 23:02:25 +0200 Message-ID: References: <909EF5E1-6F30-4A35-84E8-2EF4333115FD@gmail.com> <4996E536-72CE-4E6A-9C75-CF7307A82469@gmail.com> Reply-To: Rudolf =?UTF-8?Q?Adamkovi=C4=8D?= Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30556"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60830@debbugs.gnu.org, Stefan Kangas , Stefan Monnier To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 07 23:03:10 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qpES6-0007i8-ME for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 07 Oct 2023 23:03:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qpERn-00046m-Ts; Sat, 07 Oct 2023 17:02:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qpERg-00044c-Hb for bug-gnu-emacs@gnu.org; Sat, 07 Oct 2023 17:02:46 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qpERf-0004Wx-I1 for bug-gnu-emacs@gnu.org; Sat, 07 Oct 2023 17:02:44 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qpERy-0007GK-FO for bug-gnu-emacs@gnu.org; Sat, 07 Oct 2023 17:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Rudolf =?UTF-8?Q?Adamkovi=C4=8D?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Oct 2023 21:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60830 X-GNU-PR-Package: emacs Original-Received: via spool by 60830-submit@debbugs.gnu.org id=B60830.169671257727903 (code B ref 60830); Sat, 07 Oct 2023 21:03:02 +0000 Original-Received: (at 60830) by debbugs.gnu.org; 7 Oct 2023 21:02:57 +0000 Original-Received: from localhost ([127.0.0.1]:55989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qpERs-0007Fy-Vl for submit@debbugs.gnu.org; Sat, 07 Oct 2023 17:02:57 -0400 Original-Received: from qs51p00im-qukt01072102.me.com ([17.57.155.11]:54953) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qpERr-0007Fk-0z for 60830@debbugs.gnu.org; Sat, 07 Oct 2023 17:02:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1696712549; bh=QFVa8eNAnZ2A67bHdtUMK/DUrRQHmiqEPY3EswtNfVY=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=WgOdUcKMtfQ32Fm9jnqWAwB05x+o8MBixl3Ur1M1MFvVD+PYpk2+3OJ7fz64SjfsC PQ5jy1wZ/5NPm+1t5dtpYrQDNyV1nXBheDN3Nz5WFmR7ICmnw6z7Fq9dCMB2ic4bHE 4E6Jhdw7341TT4LgRL2C2teN/98TzlJJOCxPgZJKFQKjkLTX5dkdD1DxUOUMIEyuR8 vEWTqliz4wDKh8fcEOsA4yn/SqfDpCgTLc1nww3bxF4zzCA5bSyJIhcq3ajut/hk19 L/3s7sU8POpdm6XmYGav6coyI9W4TNe4VbIbEcodEUj4cliFxoiP8U7m8gnEpLO1tw JX81tzQIRYqog== Original-Received: from Rudolfs-MacBook-Air.local (qs51p00im-dlb-asmtp-mailmevip.me.com [17.57.155.28]) by qs51p00im-qukt01072102.me.com (Postfix) with ESMTPSA id 86D72340214; Sat, 7 Oct 2023 21:02:28 +0000 (UTC) In-Reply-To: <4996E536-72CE-4E6A-9C75-CF7307A82469@gmail.com> X-Proofpoint-ORIG-GUID: bChcAAy6_AjTY8zKWz_RnKasq6pSCmK6 X-Proofpoint-GUID: bChcAAy6_AjTY8zKWz_RnKasq6pSCmK6 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.1.170-22c6f66c430a71ce266a39bfe25bc2903e8d5c8f:6.0.425, 18.0.572, 17.0.605.474.0000000 definitions=2022-01-11_01:2022-01-11_01, 2020-02-14_11, 2020-01-23_02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 mlxscore=0 bulkscore=0 clxscore=1015 spamscore=0 suspectscore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2310070193 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:272048 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mattias Engdeg=C3=A5rd 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 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Make-the-Compilation-mode-recognize-Lua-errors.patch >From 0d2e317efd7f66d5605cd804648d30f7beef6709 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 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) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable --=20 "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=C4=8D [he/him] Studenohorsk=C3=A1 25 84103 Bratislava Slovakia --=-=-=--