* bug#39595: M-x compile still very line-length weak
@ 2020-02-13 5:51 積丹尼 Dan Jacobson
2020-02-14 11:18 ` bug#39595: #39595: " Mattias Engdegård
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: 積丹尼 Dan Jacobson @ 2020-02-13 5:51 UTC (permalink / raw)
To: 39595
Compare M-x compile on make aaa vs. make bbb
$ cat Makefile
aaa:; perl -we 'print " " x 9999;' #finishes right away.
bbb:; perl -we 'print "\n" x 9999;' #takes several seconds, even on the latest hardware.
(Indeed, on even longer lines we even see both the words "exit" and "Compiling" at the same time in the modeline.)
emacs-version "26.3"
^ permalink raw reply [flat|nested] 12+ messages in thread* bug#39595: #39595: M-x compile still very line-length weak 2020-02-13 5:51 bug#39595: M-x compile still very line-length weak 積丹尼 Dan Jacobson @ 2020-02-14 11:18 ` Mattias Engdegård 2020-02-14 16:27 ` Mattias Engdegård 2020-02-15 1:28 ` 積丹尼 Dan Jacobson 2020-02-16 15:37 ` 積丹尼 Dan Jacobson 2 siblings, 1 reply; 12+ messages in thread From: Mattias Engdegård @ 2020-02-14 11:18 UTC (permalink / raw) To: 積丹尼 Dan Jacobson; +Cc: 39595 > aaa:; perl -we 'print " " x 9999;' #finishes right away. > bbb:; perl -we 'print "\n" x 9999;' #takes several seconds, even on the latest hardware. (The comments seem to have been swapped around, but we get the idea.) This is not a rare edge case. Long lines are not uncommon in compilation output, and a sluggish M-x compile reflects badly on Emacs since it is a commonly used function. The main culprit seems to be 'omake' -- try removing it from compilation-error-regexp-alist. There is still an annoying delay; further investigation is needed. (For instance, 'msft' occurs twice; this must be a mistake.) ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#39595: #39595: M-x compile still very line-length weak 2020-02-14 11:18 ` bug#39595: #39595: " Mattias Engdegård @ 2020-02-14 16:27 ` Mattias Engdegård 2020-02-14 17:00 ` Eli Zaretskii 0 siblings, 1 reply; 12+ messages in thread From: Mattias Engdegård @ 2020-02-14 16:27 UTC (permalink / raw) To: 積丹尼 Dan Jacobson, Eli Zaretskii, Stefan Monnier, Paul Pogonyshev Cc: 39595 Dan, in your example you used a long line of spaces. Presumably that is representative for your particular use, but different message parsers are sensitive to different kinds of long lines: * 'omake' in compilation-error-regexp-alist is indeed what makes Emacs unusably slow with long lines of spaces. * 'msft' and 'watcom' are both expensive with long lines of spaces, but not as bad as 'omake'. Maybe these regexps can be tuned further. * 'msft' occurs twice by mistake; the last one should be removed. This helps a bit. * 'maven' is still expensive for long lines of non-spaces; see bug#3441. Anchoring the match at line-start would fix it: (rx bol (? "[" (or "ERROR" (group "WARNING") (group "INFO")) "]" (+ " ")) (group (not (in "\n ")) (* (or (not (in "\n :")) (: " " (not (in "\n/-"))) (: ":" (not (in "\n [")))))) ":[" (group (+ digit)) "," (group (+ digit)) "] ") Is that correct? (CC:ing Paul Pogonyshev, who worked on that regexp in bug#20556.) I suggest we disable omake by default --- although a nice tool, it was never widely used, and OCaml programmers tend to use Dune (or plain Make) these days. The omake rule will still be there for those who need it, but the majority shouldn't bear the cost. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#39595: #39595: M-x compile still very line-length weak 2020-02-14 16:27 ` Mattias Engdegård @ 2020-02-14 17:00 ` Eli Zaretskii 2020-02-14 22:47 ` Mattias Engdegård 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2020-02-14 17:00 UTC (permalink / raw) To: Mattias Engdegård; +Cc: 39595, jidanni, pogonyshev, monnier > From: Mattias Engdegård <mattiase@acm.org> > Date: Fri, 14 Feb 2020 17:27:39 +0100 > Cc: 39595@debbugs.gnu.org > > I suggest we disable omake by default --- although a nice tool, it was never widely used, and OCaml programmers tend to use Dune (or plain Make) these days. The omake rule will still be there for those who need it, but the majority shouldn't bear the cost. Is there some forum where the relevant people could be asked about this? ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#39595: #39595: M-x compile still very line-length weak 2020-02-14 17:00 ` Eli Zaretskii @ 2020-02-14 22:47 ` Mattias Engdegård 2020-02-15 7:35 ` Eli Zaretskii 0 siblings, 1 reply; 12+ messages in thread From: Mattias Engdegård @ 2020-02-14 22:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 39595, jidanni, pogonyshev, monnier [-- Attachment #1: Type: text/plain, Size: 702 bytes --] 14 feb. 2020 kl. 18.00 skrev Eli Zaretskii <eliz@gnu.org>: > Is there some forum where the relevant people could be asked about > this? Not sure where to go for that. The problem is really in Emacs's hacky implementation: when 'omake' is included in compilation-error-regexp-alist, many other regexps are rewritten in a way that makes them potentially slower. This is why it's not an ideal feature to have enabled by default. Attached are two patches: one that anchors the regexp for Maven, and one that speeds up 'msft' and 'watcom' by eliminating the same repetition-after-repetition flaw in each (not much different from those found by the latest relint/xr scan posted to emacs-devel). [-- Attachment #2: 0001-Speed-up-maven-compilation-error-message-regexp.patch --] [-- Type: application/octet-stream, Size: 1756 bytes --] From 3d589111903e823c9fab3a94e42a7339ad9edd89 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mattias=20Engdeg=C3=A5rd?= <mattiase@acm.org> Date: Fri, 14 Feb 2020 21:26:20 +0100 Subject: [PATCH 1/2] Speed up 'maven' compilation error message regexp Anchor the regexp at line-start to prevent quadratic behaviour when it doesn't match (bug#39595). * lisp/progmodes/compile.el (compilation-error-regexp-alist-alist): Rewrite 'maven' regexp, using rx for clarity. --- lisp/progmodes/compile.el | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el index 48ac85a73b..65c2978c9e 100644 --- a/lisp/progmodes/compile.el +++ b/lisp/progmodes/compile.el @@ -273,7 +273,23 @@ compilation-error-regexp-alist-alist ;; due to matching filenames via \\(.*?\\). This might be faster. (maven ;; Maven is a popular free software build tool for Java. - "\\(\\[WARNING\\] *\\)?\\([^ \n]\\(?:[^\n :]\\| [^-/\n]\\|:[^ \n]\\)*?\\):\\[\\([0-9]+\\),\\([0-9]+\\)\\] " 2 3 4 (1)) + ,(rx bol + (? (* " ") + "[" + (or "ERROR" (group-n 1 "WARNING") (group-n 2 "INFO")) + "]" + (+ " ")) + (group-n 3 + (not (any "\n ")) + (* (| (not (any "\n :")) + (: " " (not (any "\n/-"))) + (: ":" (not (any "\n [")))))) + ":[" + (group-n 4 (+ digit)) + "," + (group-n 5 (+ digit)) + "] ") + 3 4 5 (1 . 2)) (jikes-line "^ *\\([0-9]+\\)\\.[ \t]+.*\n +\\(<-*>\n\\*\\*\\* \\(?:Error\\|Warnin\\(g\\)\\)\\)" -- 2.21.1 (Apple Git-122.3) [-- Attachment #3: 0002-Speed-up-msft-and-watcom-compilation-error-regexps.patch --] [-- Type: application/octet-stream, Size: 1705 bytes --] From 5d749520ddde466fd8ae5412ace567a7e6cc313b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mattias=20Engdeg=C3=A5rd?= <mattiase@acm.org> Date: Fri, 14 Feb 2020 23:38:24 +0100 Subject: [PATCH 2/2] Speed up 'msft' and 'watcom' compilation error regexps They have similar structure, and both suffer from being able to match leading spaces in multiple ways which leads to bad performance when backtracking (bug#39595). * lisp/progmodes/compile.el (compilation-error-regexp-alist-alist): Improved 'msft' and 'watcom' regexps. --- lisp/progmodes/compile.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el index 65c2978c9e..79d2293e21 100644 --- a/lisp/progmodes/compile.el +++ b/lisp/progmodes/compile.el @@ -221,7 +221,7 @@ compilation-error-regexp-alist-alist ;; considered before EDG. ;; The message may be a "warning", "error", or "fatal error" with ;; an error code, or "see declaration of" without an error code. - "^ *\\([0-9]+>\\)?\\(\\(?:[a-zA-Z]:\\)?[^:(\t\n]+\\)(\\([0-9]+\\)) ?\ + "^ *\\([0-9]+>\\)?\\(\\(?:[a-zA-Z]:\\)?[^ :(\t\n][^:(\t\n]*\\)(\\([0-9]+\\)) ?\ : \\(?:see declaration\\|\\(?:warnin\\(g\\)\\|[a-z ]+\\) C[0-9]+:\\)" 2 3 nil (4)) @@ -459,7 +459,7 @@ compilation-error-regexp-alist-alist "^\\([^, \n\t]+\\), line \\([0-9]+\\), char \\([0-9]+\\)[:., (-]" 1 2 3) (watcom - "^[ \t]*\\(\\(?:[a-zA-Z]:\\)?[^:(\t\n]+\\)(\\([0-9]+\\)): ?\ + "^[ \t]*\\(\\(?:[a-zA-Z]:\\)?[^ :(\t\n][^:(\t\n]*\\)(\\([0-9]+\\)): ?\ \\(?:\\(Error! E[0-9]+\\)\\|\\(Warning! W[0-9]+\\)\\):" 1 2 nil (4)) -- 2.21.1 (Apple Git-122.3) ^ permalink raw reply related [flat|nested] 12+ messages in thread
* bug#39595: #39595: M-x compile still very line-length weak 2020-02-14 22:47 ` Mattias Engdegård @ 2020-02-15 7:35 ` Eli Zaretskii 2020-02-15 16:45 ` Mattias Engdegård 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2020-02-15 7:35 UTC (permalink / raw) To: Mattias Engdegård; +Cc: 39595, jidanni, pogonyshev, monnier > From: Mattias Engdegård <mattiase@acm.org> > Date: Fri, 14 Feb 2020 23:47:43 +0100 > Cc: jidanni@jidanni.org, monnier@iro.umontreal.ca, pogonyshev@gmail.com, > 39595@debbugs.gnu.org > > > Is there some forum where the relevant people could be asked about > > this? > > Not sure where to go for that. The problem is really in Emacs's hacky implementation: when 'omake' is included in compilation-error-regexp-alist, many other regexps are rewritten in a way that makes them potentially slower. This is why it's not an ideal feature to have enabled by default. I'm okay with disabling 'omake' if we have nowhere else to ask. Thanks. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#39595: #39595: M-x compile still very line-length weak 2020-02-15 7:35 ` Eli Zaretskii @ 2020-02-15 16:45 ` Mattias Engdegård 2020-02-16 12:15 ` Mattias Engdegård 0 siblings, 1 reply; 12+ messages in thread From: Mattias Engdegård @ 2020-02-15 16:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 39595, jidanni, pogonyshev, monnier [-- Attachment #1: Type: text/plain, Size: 715 bytes --] 15 feb. 2020 kl. 08.35 skrev Eli Zaretskii <eliz@gnu.org>: > I'm okay with disabling 'omake' if we have nowhere else to ask. We may not have to, after all. Reading the OMake sources, it very much looks like errors are indented by exactly 6 spaces, which means that we can replace (* " ") with (? "6 spaces") which is a lot faster. Having done that, it turned out that recognising ruby-Test::Unit errors depended on the old 'omake' regexp rewriting (another reason to disable omake by default, perhaps), so that regexp had to be fixed as well. Along with the two previous patches (for msft, watcom and maven), this should reduce the cost of long lines to something more tolerable for the time being. [-- Attachment #2: 0001-Make-OMake-support-slightly-less-expensive-bug-39595.patch --] [-- Type: application/octet-stream, Size: 4598 bytes --] From 79f816e614218bce2c15d550bc2cf1a591f22e43 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mattias=20Engdeg=C3=A5rd?= <mattiase@acm.org> Date: Sat, 15 Feb 2020 16:08:14 +0100 Subject: [PATCH] Make OMake support slightly less expensive (bug#39595) When run with -p or -P, OMake regurgitates error messages that prevented further progress, indented by 6 spaces. Use that fact to ameliorate the modification done to other error message regexps. * lisp/progmodes/compile.el (compilation-parse-errors): When 'omake' is enabled, allow error messages to be indented by 0 or 6 spaces instead of any number of spaces, to avoid pathological behaviour. (compilation-error-regexp-alist-alist): Anchor the 'omake' pattern to bol for performance. Repair the 'ruby-Test::Unit' pattern, which relied on the previously over-generous 'omake' hack. * etc/compilation.txt (OMake): Add examples. * test/lisp/progmodes/compile-tests.el (compile-tests--test-regexps-data) (compile-test-error-regexps): Add test for OMake (indented error). --- etc/compilation.txt | 16 ++++++++++++++++ lisp/progmodes/compile.el | 6 +++--- test/lisp/progmodes/compile-tests.el | 5 ++++- 3 files changed, 23 insertions(+), 4 deletions(-) diff --git a/etc/compilation.txt b/etc/compilation.txt index a597216daa..69db891907 100644 --- a/etc/compilation.txt +++ b/etc/compilation.txt @@ -382,6 +382,22 @@ symbol: watcom ..\src\ctrl\lister.c(120): Warning! W201: Unreachable code +* OMake + +symbol: omake + +When using in -p or -P mode, OMake will detect changes to files and +report critical build errors indented by 6 spaces. + +*** omake: file alpha.c changed +*** omake: targets were not rebuilt because of errors: + alpha.o + depends on: alpha.c + - build . alpha.o + + cc -I. -c -o alpha.o alpha.c + alpha.c:5:15: error: expected ';' after expression + + * Oracle pro*c symbol: oracle diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el index 79d2293e21..dcd2e59f10 100644 --- a/lisp/progmodes/compile.el +++ b/lisp/progmodes/compile.el @@ -310,7 +310,7 @@ compilation-error-regexp-alist-alist 1 2 3 (4 . 5)) (ruby-Test::Unit - "^[\t ]*\\[\\([^(].*\\):\\([1-9][0-9]*\\)\\(\\]\\)?:in " 1 2) + "^ [[ ]?\\([^ (].*\\):\\([1-9][0-9]*\\)\\(\\]\\)?:in " 1 2) (gmake ;; Set GNU make error messages as INFO level. @@ -410,7 +410,7 @@ compilation-error-regexp-alist-alist (omake ;; "omake -P" reports "file foo changed" ;; (useful if you do "cvs up" and want to see what has changed) - "omake: file \\(.*\\) changed" 1 nil nil nil nil + "^\\*\\*\\* omake: file \\(.*\\) changed" 1 nil nil nil nil ;; FIXME-omake: This tries to prevent reusing pre-existing markers ;; for subsequent messages, since those messages's line numbers ;; are about another version of the file. @@ -1457,7 +1457,7 @@ compilation-parse-errors ((not (memq 'omake compilation-error-regexp-alist)) nil) ((string-match "\\`\\([^^]\\|\\^\\( \\*\\|\\[\\)\\)" pat) nil) ;; Not anchored or anchored but already allows empty spaces. - (t (setq pat (concat "^ *" (substring pat 1))))) + (t (setq pat (concat "^\\(?: \\)?" (substring pat 1))))) (if (consp file) (setq fmt (cdr file) file (car file))) (if (consp line) (setq end-line (cdr line) line (car line))) diff --git a/test/lisp/progmodes/compile-tests.el b/test/lisp/progmodes/compile-tests.el index 350b4eb400..01db77c9c3 100644 --- a/test/lisp/progmodes/compile-tests.el +++ b/test/lisp/progmodes/compile-tests.el @@ -269,6 +269,9 @@ compile-tests--test-regexps-data 1 nil 109 "..\\src\\ctrl\\lister.c") ("..\\src\\ctrl\\lister.c(120): Warning! W201: Unreachable code" 1 nil 120 "..\\src\\ctrl\\lister.c") + ;; omake + (" alpha.c:5:15: error: expected ';' after expression" + 1 15 5 "alpha.c") ;; oracle ("Semantic error at line 528, column 5, file erosacqdb.pc:" 1 5 528 "erosacqdb.pc") @@ -428,7 +431,7 @@ compile-test-error-regexps (compilation-num-warnings-found 0) (compilation-num-infos-found 0)) (mapc #'compile--test-error-line compile-tests--test-regexps-data) - (should (eq compilation-num-errors-found 92)) + (should (eq compilation-num-errors-found 93)) (should (eq compilation-num-warnings-found 36)) (should (eq compilation-num-infos-found 26))))) -- 2.21.1 (Apple Git-122.3) ^ permalink raw reply related [flat|nested] 12+ messages in thread
* bug#39595: #39595: M-x compile still very line-length weak 2020-02-15 16:45 ` Mattias Engdegård @ 2020-02-16 12:15 ` Mattias Engdegård 0 siblings, 0 replies; 12+ messages in thread From: Mattias Engdegård @ 2020-02-16 12:15 UTC (permalink / raw) To: 積丹尼 Dan Jacobson Cc: 39595, Stefan Monnier, Paul Pogonyshev [-- Attachment #1: Type: text/plain, Size: 159 bytes --] To wrap it up, here are the three patches (intended to be used together). The Maven patch was tweaked further for efficiency. Dan, is this satisfactory? [-- Attachment #2: 0001-Speed-up-maven-compilation-error-message-regexp.patch --] [-- Type: application/octet-stream, Size: 3566 bytes --] From 1a5a9ac17e227f32608dd6fe2c040ebd87cf3602 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mattias=20Engdeg=C3=A5rd?= <mattiase@acm.org> Date: Fri, 14 Feb 2020 21:26:20 +0100 Subject: [PATCH 1/3] Speed up 'maven' compilation error message regexp Anchor the regexp at line-start to prevent quadratic behaviour when it doesn't match (bug#39595). It's unclear whether the type tag, like [ERROR], is always present; we keep it optional just in case. * lisp/progmodes/compile.el (compilation-error-regexp-alist-alist): Rewrite 'maven' regexp, using rx for clarity. * etc/compilation.txt (maven): More examples. * test/lisp/progmodes/compile-tests.el (compile-tests--test-regexps-data): No leading spaces; they seems to stem from a misunderstanding in bug#11517. --- etc/compilation.txt | 2 ++ lisp/progmodes/compile.el | 20 ++++++++++++++++---- test/lisp/progmodes/compile-tests.el | 2 +- 3 files changed, 19 insertions(+), 5 deletions(-) diff --git a/etc/compilation.txt b/etc/compilation.txt index a597216daa..c465b4b94a 100644 --- a/etc/compilation.txt +++ b/etc/compilation.txt @@ -341,6 +341,8 @@ makepp: bla bla `/foo/bar.c' and `/foo/bar.h' symbol: maven FooBar.java:[111,53] no interface expected here +[ERROR] /Users/cinsk/hello.java:[651,96] ';' expected +[WARNING] /foo/bar/Test.java:[27,43] unchecked conversion * MIPS lint; looks good for SunPro lint also diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el index 48ac85a73b..9959c829df 100644 --- a/lisp/progmodes/compile.el +++ b/lisp/progmodes/compile.el @@ -268,12 +268,24 @@ compilation-error-regexp-alist-alist (jikes-file "^\\(?:Found\\|Issued\\) .* compiling \"\\(.+\\)\":$" 1 nil nil 0) - - ;; This used to be pathologically slow on long lines (Bug#3441), - ;; due to matching filenames via \\(.*?\\). This might be faster. (maven ;; Maven is a popular free software build tool for Java. - "\\(\\[WARNING\\] *\\)?\\([^ \n]\\(?:[^\n :]\\| [^-/\n]\\|:[^ \n]\\)*?\\):\\[\\([0-9]+\\),\\([0-9]+\\)\\] " 2 3 4 (1)) + ,(rx bol + ;; It is unclear whether the initial [type] tag is always present. + (? "[" + (or "ERROR" (group-n 1 "WARNING") (group-n 2 "INFO")) + "] ") + (group-n 3 ; File + (not (any "\n [")) + (* (or (not (any "\n :")) + (: " " (not (any "\n/-"))) + (: ":" (not (any "\n [")))))) + ":[" + (group-n 4 (+ digit)) ; Line + "," + (group-n 5 (+ digit)) ; Column + "] ") + 3 4 5 (1 . 2)) (jikes-line "^ *\\([0-9]+\\)\\.[ \t]+.*\n +\\(<-*>\n\\*\\*\\* \\(?:Error\\|Warnin\\(g\\)\\)\\)" diff --git a/test/lisp/progmodes/compile-tests.el b/test/lisp/progmodes/compile-tests.el index 350b4eb400..c3cec01f8b 100644 --- a/test/lisp/progmodes/compile-tests.el +++ b/test/lisp/progmodes/compile-tests.el @@ -242,7 +242,7 @@ compile-tests--test-regexps-data ;; maven ("FooBar.java:[111,53] no interface expected here" 1 53 111 "FooBar.java" 2) - (" [ERROR] /Users/cinsk/hello.java:[651,96] ';' expected" + ("[ERROR] /Users/cinsk/hello.java:[651,96] ';' expected" 15 96 651 "/Users/cinsk/hello.java" 2) ;Bug#11517. ("[WARNING] /foo/bar/Test.java:[27,43] unchecked conversion" 11 43 27 "/foo/bar/Test.java" 1) ;Bug#20556 -- 2.21.1 (Apple Git-122.3) [-- Attachment #3: 0002-Speed-up-msft-and-watcom-compilation-error-regexps.patch --] [-- Type: application/octet-stream, Size: 1705 bytes --] From 8689105a957e70c127d2f39ea8e4c0fcc141e2a7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mattias=20Engdeg=C3=A5rd?= <mattiase@acm.org> Date: Fri, 14 Feb 2020 23:38:24 +0100 Subject: [PATCH 2/3] Speed up 'msft' and 'watcom' compilation error regexps They have similar structure, and both suffer from being able to match leading spaces in multiple ways which leads to bad performance when backtracking (bug#39595). * lisp/progmodes/compile.el (compilation-error-regexp-alist-alist): Improved 'msft' and 'watcom' regexps. --- lisp/progmodes/compile.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el index 9959c829df..21c3153b8a 100644 --- a/lisp/progmodes/compile.el +++ b/lisp/progmodes/compile.el @@ -221,7 +221,7 @@ compilation-error-regexp-alist-alist ;; considered before EDG. ;; The message may be a "warning", "error", or "fatal error" with ;; an error code, or "see declaration of" without an error code. - "^ *\\([0-9]+>\\)?\\(\\(?:[a-zA-Z]:\\)?[^:(\t\n]+\\)(\\([0-9]+\\)) ?\ + "^ *\\([0-9]+>\\)?\\(\\(?:[a-zA-Z]:\\)?[^ :(\t\n][^:(\t\n]*\\)(\\([0-9]+\\)) ?\ : \\(?:see declaration\\|\\(?:warnin\\(g\\)\\|[a-z ]+\\) C[0-9]+:\\)" 2 3 nil (4)) @@ -455,7 +455,7 @@ compilation-error-regexp-alist-alist "^\\([^, \n\t]+\\), line \\([0-9]+\\), char \\([0-9]+\\)[:., (-]" 1 2 3) (watcom - "^[ \t]*\\(\\(?:[a-zA-Z]:\\)?[^:(\t\n]+\\)(\\([0-9]+\\)): ?\ + "^[ \t]*\\(\\(?:[a-zA-Z]:\\)?[^ :(\t\n][^:(\t\n]*\\)(\\([0-9]+\\)): ?\ \\(?:\\(Error! E[0-9]+\\)\\|\\(Warning! W[0-9]+\\)\\):" 1 2 nil (4)) -- 2.21.1 (Apple Git-122.3) [-- Attachment #4: 0003-Make-OMake-support-slightly-less-expensive-bug-39595.patch --] [-- Type: application/octet-stream, Size: 4602 bytes --] From aa5b0aa200a5c045a89dd8e349de34a128f3c9c7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mattias=20Engdeg=C3=A5rd?= <mattiase@acm.org> Date: Sat, 15 Feb 2020 16:08:14 +0100 Subject: [PATCH 3/3] Make OMake support slightly less expensive (bug#39595) When run with -p or -P, OMake regurgitates error messages that prevented further progress, indented by 6 spaces. Use that fact to ameliorate the modification done to other error message regexps. * lisp/progmodes/compile.el (compilation-parse-errors): When 'omake' is enabled, allow error messages to be indented by 0 or 6 spaces instead of any number of spaces, to avoid pathological behaviour. (compilation-error-regexp-alist-alist): Anchor the 'omake' pattern to bol for performance. Repair the 'ruby-Test::Unit' pattern, which relied on the previously over-generous 'omake' hack. * etc/compilation.txt (OMake): Add examples. * test/lisp/progmodes/compile-tests.el (compile-tests--test-regexps-data) (compile-test-error-regexps): Add test for OMake (indented error). --- etc/compilation.txt | 16 ++++++++++++++++ lisp/progmodes/compile.el | 6 +++--- test/lisp/progmodes/compile-tests.el | 5 ++++- 3 files changed, 23 insertions(+), 4 deletions(-) diff --git a/etc/compilation.txt b/etc/compilation.txt index c465b4b94a..ebce6a14d0 100644 --- a/etc/compilation.txt +++ b/etc/compilation.txt @@ -384,6 +384,22 @@ symbol: watcom ..\src\ctrl\lister.c(120): Warning! W201: Unreachable code +* OMake + +symbol: omake + +When using in -p or -P mode, OMake will detect changes to files and +report critical build errors indented by 6 spaces. + +*** omake: file alpha.c changed +*** omake: targets were not rebuilt because of errors: + alpha.o + depends on: alpha.c + - build . alpha.o + + cc -I. -c -o alpha.o alpha.c + alpha.c:5:15: error: expected ';' after expression + + * Oracle pro*c symbol: oracle diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el index 21c3153b8a..455f181f50 100644 --- a/lisp/progmodes/compile.el +++ b/lisp/progmodes/compile.el @@ -306,7 +306,7 @@ compilation-error-regexp-alist-alist 1 2 3 (4 . 5)) (ruby-Test::Unit - "^[\t ]*\\[\\([^(].*\\):\\([1-9][0-9]*\\)\\(\\]\\)?:in " 1 2) + "^ [[ ]?\\([^ (].*\\):\\([1-9][0-9]*\\)\\(\\]\\)?:in " 1 2) (gmake ;; Set GNU make error messages as INFO level. @@ -406,7 +406,7 @@ compilation-error-regexp-alist-alist (omake ;; "omake -P" reports "file foo changed" ;; (useful if you do "cvs up" and want to see what has changed) - "omake: file \\(.*\\) changed" 1 nil nil nil nil + "^\\*\\*\\* omake: file \\(.*\\) changed" 1 nil nil nil nil ;; FIXME-omake: This tries to prevent reusing pre-existing markers ;; for subsequent messages, since those messages's line numbers ;; are about another version of the file. @@ -1453,7 +1453,7 @@ compilation-parse-errors ((not (memq 'omake compilation-error-regexp-alist)) nil) ((string-match "\\`\\([^^]\\|\\^\\( \\*\\|\\[\\)\\)" pat) nil) ;; Not anchored or anchored but already allows empty spaces. - (t (setq pat (concat "^ *" (substring pat 1))))) + (t (setq pat (concat "^\\(?: \\)?" (substring pat 1))))) (if (consp file) (setq fmt (cdr file) file (car file))) (if (consp line) (setq end-line (cdr line) line (car line))) diff --git a/test/lisp/progmodes/compile-tests.el b/test/lisp/progmodes/compile-tests.el index c3cec01f8b..75962566f1 100644 --- a/test/lisp/progmodes/compile-tests.el +++ b/test/lisp/progmodes/compile-tests.el @@ -269,6 +269,9 @@ compile-tests--test-regexps-data 1 nil 109 "..\\src\\ctrl\\lister.c") ("..\\src\\ctrl\\lister.c(120): Warning! W201: Unreachable code" 1 nil 120 "..\\src\\ctrl\\lister.c") + ;; omake + (" alpha.c:5:15: error: expected ';' after expression" + 1 15 5 "alpha.c") ;; oracle ("Semantic error at line 528, column 5, file erosacqdb.pc:" 1 5 528 "erosacqdb.pc") @@ -428,7 +431,7 @@ compile-test-error-regexps (compilation-num-warnings-found 0) (compilation-num-infos-found 0)) (mapc #'compile--test-error-line compile-tests--test-regexps-data) - (should (eq compilation-num-errors-found 92)) + (should (eq compilation-num-errors-found 93)) (should (eq compilation-num-warnings-found 36)) (should (eq compilation-num-infos-found 26))))) -- 2.21.1 (Apple Git-122.3) [-- Attachment #5: Type: text/plain, Size: 2 bytes --] ^ permalink raw reply related [flat|nested] 12+ messages in thread
* bug#39595: #39595: M-x compile still very line-length weak 2020-02-13 5:51 bug#39595: M-x compile still very line-length weak 積丹尼 Dan Jacobson 2020-02-14 11:18 ` bug#39595: #39595: " Mattias Engdegård @ 2020-02-15 1:28 ` 積丹尼 Dan Jacobson 2020-02-15 13:57 ` Stefan Monnier 2020-02-16 15:37 ` 積丹尼 Dan Jacobson 2 siblings, 1 reply; 12+ messages in thread From: 積丹尼 Dan Jacobson @ 2020-02-15 1:28 UTC (permalink / raw) To: Mattias Engdegård; +Cc: 39595, Stefan Monnier, Paul Pogonyshev (Yeah I got my comments backwards.) Anyway I recall perl is fast on regexps, newlines or not. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#39595: #39595: M-x compile still very line-length weak 2020-02-15 1:28 ` 積丹尼 Dan Jacobson @ 2020-02-15 13:57 ` Stefan Monnier 0 siblings, 0 replies; 12+ messages in thread From: Stefan Monnier @ 2020-02-15 13:57 UTC (permalink / raw) To: 積丹尼 Dan Jacobson Cc: 39595, Mattias Engdegård, Paul Pogonyshev > Anyway I recall perl is fast on regexps, newlines or not. That's just a reputation. In reality, maybe its constant is lower than that of Emacs's regexp matcher, and maybe it implements a few more optimisations, but it suffers from the same explosion as Emacs's regexp matcher with regexps like the one under discussions (i.e. when Emacs's regexps are slow, it's because of the basty complexity introduced by backtracking and Perl's regexps do backtracking more or less as much as Emacs's). Stefan ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#39595: #39595: M-x compile still very line-length weak 2020-02-13 5:51 bug#39595: M-x compile still very line-length weak 積丹尼 Dan Jacobson 2020-02-14 11:18 ` bug#39595: #39595: " Mattias Engdegård 2020-02-15 1:28 ` 積丹尼 Dan Jacobson @ 2020-02-16 15:37 ` 積丹尼 Dan Jacobson 2020-02-17 11:07 ` Mattias Engdegård 2 siblings, 1 reply; 12+ messages in thread From: 積丹尼 Dan Jacobson @ 2020-02-16 15:37 UTC (permalink / raw) To: Mattias Engdegård; +Cc: 39595, Stefan Monnier, Paul Pogonyshev >>>>> "ME" == Mattias Engdegård <mattiase@acm.org> writes: ME> Dan, is this satisfactory? I bet it does! (All I know is I just use Debian sid. So in two years...) ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#39595: #39595: M-x compile still very line-length weak 2020-02-16 15:37 ` 積丹尼 Dan Jacobson @ 2020-02-17 11:07 ` Mattias Engdegård 0 siblings, 0 replies; 12+ messages in thread From: Mattias Engdegård @ 2020-02-17 11:07 UTC (permalink / raw) To: 積丹尼 Dan Jacobson Cc: 39595-done, Stefan Monnier, Paul Pogonyshev 16 feb. 2020 kl. 16.37 skrev 積丹尼 Dan Jacobson <jidanni@jidanni.org>: > I bet it does! > (All I know is I just use Debian sid. So in two years...) Very well, pushed to emacs-27. For future work, there seem to be more opportunities for speeding up the remaining regexps. In particular: * Try to anchor matches at bol when possible. * Avoid infinite repetitions (of spaces, etc) when the exact amount is known. * Reject impossible matches as early as possible. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-02-17 11:07 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-02-13 5:51 bug#39595: M-x compile still very line-length weak 積丹尼 Dan Jacobson 2020-02-14 11:18 ` bug#39595: #39595: " Mattias Engdegård 2020-02-14 16:27 ` Mattias Engdegård 2020-02-14 17:00 ` Eli Zaretskii 2020-02-14 22:47 ` Mattias Engdegård 2020-02-15 7:35 ` Eli Zaretskii 2020-02-15 16:45 ` Mattias Engdegård 2020-02-16 12:15 ` Mattias Engdegård 2020-02-15 1:28 ` 積丹尼 Dan Jacobson 2020-02-15 13:57 ` Stefan Monnier 2020-02-16 15:37 ` 積丹尼 Dan Jacobson 2020-02-17 11:07 ` Mattias Engdegård
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).