GNU bug report logs -
#58007
28.1; compilation-error-properties skips non-matching FILE indices
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On Fri, Sep 23, 2022 at 6:10 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Do you have a test case that demonstrates the problem?
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.
> 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.
[rebar3-dialyzer-example-output (application/octet-stream, attachment)]
This bug report was last modified 1 year and 213 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.