unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Axel Forsman <axelsfor@gmail.com>
Cc: 58007@debbugs.gnu.org
Subject: bug#58007: 28.1; compilation-error-properties skips non-matching FILE indices
Date: Sat, 24 Sep 2022 12:29:53 +0200	[thread overview]
Message-ID: <8735ch12vy.fsf@gnus.org> (raw)
In-Reply-To: <CAPt4RUqwDE_tT=opK_J2TL0e3tkzTm9diNJ4ueo6qtBNV2y_dQ@mail.gmail.com> (Axel Forsman's message of "Fri, 23 Sep 2022 20:29:12 +0200")

Axel Forsman <axelsfor@gmail.com> writes:

> Yes, so what I initially wanted to do was parse dialyzer errors
> when running using the rebar3 package manager with `rebar3 dialyzer`.
> See attachment for example output.
>
> This is what I ended up with
>
>     (setq compilation-error-regexp-alist
>           (cons
>            '("^\\(?:\n\\(.*\\)\n\\)?Line \\([0-9]+\\)\\(?: Column
> \\([0-9]+\\)\\)?: " 1 2 3 1)
>            (cons
>             ;; This next error regexp should not be necessary
> according to documentation.
>             '("^Line \\([0-9]+\\)\\(?: Column \\([0-9]+\\)\\)?: " nil 1 2 1)
>             (eval (car (get 'compilation-error-regexp-alist
> 'standard-value))))))
>
> only with the 2nd error regexp does all errors get parsed.
> Though this is unexpected: In the 1st regexp
> when the first subexpression containing the file name does not match,
> the docs say it should act the same as the 2nd error regexp.
>
> When I have `eval-defun`:ed the patched version of
> `compilation-error-properties`,
> the 1st error regexp suffices as expected.

Ah, thanks.

>> I think this change might be too large to apply without having an FSF
>> copyright assignment on file -- would you be willing to sign such
>> paperwork?
>
> The patch is mostly all indentation changes,
> but yes, if needed I would be willing
> though I would have to consult with my employer first.

Reading the patch again, you're right -- since most of the changes are
indentation changes, we can apply the patch without a copyright
assignment.

However, your patch leads to a test failure -- can you have a look at
that?

Test compile-test-functions backtrace:
  file-name-absolute-p(("my-file"))
  compilation-error-properties((closure (t) nil '("my-file")) (closure
  compilation-parse-errors(1 17)
  (let ((rule (nth 0 test)) (str (nth 1 test)) (pos (nth 2 test)) (col
  (let ((ert--infos (cons (cons "testcase: " (format "%S" test)) ert--
  compile--test-error-line((my-rule "My error message" 1 (39 . 24) (12
  (let ((compilation-num-errors-found 0) (compilation-num-warnings-fou
  (progn (font-lock-mode -1) (let ((compilation-num-errors-found 0) (c
  (unwind-protect (progn (font-lock-mode -1) (let ((compilation-num-er
  (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
  (let ((temp-buffer (generate-new-buffer " *temp*" t))) (save-current
  (let* ((file-fun #'(lambda nil '("my-file"))) (line-start-fun #'(lam
  (closure (t) nil (let* ((file-fun #'(lambda nil '("my-file"))) (line
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name compile-test-functions :documentation
  ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
  ert-run-tests((not (or (tag :expensive-test) (tag :unstable))) #f(co
  ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable)))
  ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
  eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
  command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/progmodes/compile-te
  command-line()
  normal-top-level()
Test compile-test-functions condition:
    testcase: (my-rule "My error message" 1 (39 . 24) (123 . 134) "my-file" 2)
    (wrong-type-argument stringp
			 ("my-file"))
   FAILED  2/3  compile-test-functions (0.000089 sec) at lisp/progmodes/compile-tests.el:522
   passed  3/3  compile-test-grep-regexps (0.001284 sec)

Ran 3 tests, 2 results as expected, 1 unexpected (2022-09-24 12:26:55+0200, 0.083845 sec)

1 unexpected results:
   FAILED  compile-test-functions





  reply	other threads:[~2022-09-24 10:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-22 15:09 bug#58007: 28.1; compilation-error-properties skips non-matching FILE indices Axel Forsman
2022-09-23 16:10 ` Lars Ingebrigtsen
2022-09-23 18:29   ` Axel Forsman
2022-09-24 10:29     ` Lars Ingebrigtsen [this message]
2023-09-06 22:50       ` Stefan Kangas
2024-01-14  6:18         ` Stefan Kangas
2022-09-24 10:53     ` Stefan Kangas

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=8735ch12vy.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=58007@debbugs.gnu.org \
    --cc=axelsfor@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).