* bug#51882: Handle GCC's -fanalyzer output in M-x compile
@ 2021-11-15 23:13 Philip Kaludercic
2021-11-16 8:13 ` Lars Ingebrigtsen
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Philip Kaludercic @ 2021-11-15 23:13 UTC (permalink / raw)
To: 51882
[-- Attachment #1: Type: text/plain, Size: 964 bytes --]
Tags: patch
GCC's -fanalyzer generates tree-like output, with some file references
being indented like this
--8<---------------cut here---------------start------------->8---
|file.c:42
--8<---------------cut here---------------end--------------->8---
M-x compile appears to assume this means the file name is
" |file.c",
not "file.c". The following patch would fix this behaviour.
If accepted, should it be applied to emacs-28 or master?
In GNU Emacs 28.0.60 (build 14, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
of 2021-11-15 built on icterid
Repository revision: e852822f3db469c985bf022651f184d6ff2c518a
Repository branch: emacs-28
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)
Configured using:
'configure --with-native-compilation --with-x-toolkit=lucid
--with-imagemagick 'CFLAGS=-O2 -march=native -pipe' LDFLAGS=-flto'
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Improve-error-parsing-for-GCC-fanalyzer-output.patch --]
[-- Type: text/patch, Size: 1868 bytes --]
From eafefd3a92789cd50c07e6fce04c1da7ea108224 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Tue, 16 Nov 2021 00:05:11 +0100
Subject: [PATCH] Improve error parsing for GCC -fanalyzer output
* compile.el (compilation-error-regexp-alist-alist): Adjust gnu rule
* compile-tests.el (compile-tests--test-regexps-data): Add testcase
---
lisp/progmodes/compile.el | 5 ++++-
test/lisp/progmodes/compile-tests.el | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index ac26f5e934..ff0beacfc1 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -351,7 +351,10 @@ compilation-error-regexp-alist-alist
;; from Ruby, but it is unclear whether it is actually
;; used since the gcc-include rule above seems to cover
;; it.
- (regexp "[ \t]+\\(?:in \\|from\\)")))
+ (regexp "[ \t]+\\(?:in \\|from\\)")
+ ;; Skip indentation generated by tools like GCC's
+ ;; -fanalyzer.
+ (: (+ space) "|")))
;; File name group.
(group-n 1
diff --git a/test/lisp/progmodes/compile-tests.el b/test/lisp/progmodes/compile-tests.el
index 2a3bb3dafa..c714b9ecfe 100644
--- a/test/lisp/progmodes/compile-tests.el
+++ b/test/lisp/progmodes/compile-tests.el
@@ -230,6 +230,7 @@ compile-tests--test-regexps-data
(gnu "foo.c:8:23:information: message" 1 23 8 "foo.c")
(gnu "foo.c:8.23-45: Informational: message" 1 (23 . 45) (8 . nil) "foo.c")
(gnu "foo.c:8-23: message" 1 nil (8 . 23) "foo.c")
+ (gnu " |foo.c:8: message" 1 nil 8 "foo.c")
;; The next one is not in the GNU standards AFAICS.
;; Here we seem to interpret it as LINE1-LINE2.COL2.
(gnu "foo.c:8-45.3: message" 1 (nil . 3) (8 . 45) "foo.c")
--
2.30.2
[-- Attachment #3: Type: text/plain, Size: 24 bytes --]
--
Philip Kaludercic
^ permalink raw reply related [flat|nested] 8+ messages in thread* bug#51882: Handle GCC's -fanalyzer output in M-x compile
2021-11-15 23:13 bug#51882: Handle GCC's -fanalyzer output in M-x compile Philip Kaludercic
@ 2021-11-16 8:13 ` Lars Ingebrigtsen
2021-11-16 10:28 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-23 15:35 ` Mattias Engdegård
2 siblings, 0 replies; 8+ messages in thread
From: Lars Ingebrigtsen @ 2021-11-16 8:13 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: 51882
Philip Kaludercic <philipk@posteo.net> writes:
> If accepted, should it be applied to emacs-28 or master?
Makes sense to me, and it should go to master.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#51882: Handle GCC's -fanalyzer output in M-x compile
2021-11-15 23:13 bug#51882: Handle GCC's -fanalyzer output in M-x compile Philip Kaludercic
2021-11-16 8:13 ` Lars Ingebrigtsen
@ 2021-11-16 10:28 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-17 20:21 ` Philip Kaludercic
2021-11-23 15:35 ` Mattias Engdegård
2 siblings, 1 reply; 8+ messages in thread
From: Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-11-16 10:28 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: 51882
Philip Kaludercic <philipk@posteo.net> writes:
> Tags: patch
>
>
> GCC's -fanalyzer generates tree-like output, with some file references
> being indented like this
>
> |file.c:42
>
> M-x compile appears to assume this means the file name is
>
> " |file.c",
>
> not "file.c". The following patch would fix this behaviour.
>
Thanks for the patch. Should we update etc/compilation.txt as well?
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#51882: Handle GCC's -fanalyzer output in M-x compile
2021-11-16 10:28 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-11-17 20:21 ` Philip Kaludercic
0 siblings, 0 replies; 8+ messages in thread
From: Philip Kaludercic @ 2021-11-17 20:21 UTC (permalink / raw)
To: Daniel Martín; +Cc: 51882
Daniel Martín <mardani29@yahoo.es> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Tags: patch
>>
>>
>> GCC's -fanalyzer generates tree-like output, with some file references
>> being indented like this
>>
>> |file.c:42
>>
>> M-x compile appears to assume this means the file name is
>>
>> " |file.c",
>>
>> not "file.c". The following patch would fix this behaviour.
>>
>
> Thanks for the patch. Should we update etc/compilation.txt as well?
I am not familiar with that file. If it is expected, I can update it.
--
Philip Kaludercic
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#51882: Handle GCC's -fanalyzer output in M-x compile
2021-11-15 23:13 bug#51882: Handle GCC's -fanalyzer output in M-x compile Philip Kaludercic
2021-11-16 8:13 ` Lars Ingebrigtsen
2021-11-16 10:28 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-11-23 15:35 ` Mattias Engdegård
2021-11-23 18:14 ` Philip Kaludercic
2 siblings, 1 reply; 8+ messages in thread
From: Mattias Engdegård @ 2021-11-23 15:35 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: Daniel Martín, 51882
Would it be possible to see a full example, with context, of the message emitted by GCC?
I would like to understand what, exactly, this regexp is supposed to be parsing. I've simplified the regexp in compile.el a little but want to be sure that I'm not making any mistakes.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#51882: Handle GCC's -fanalyzer output in M-x compile
2021-11-23 15:35 ` Mattias Engdegård
@ 2021-11-23 18:14 ` Philip Kaludercic
2021-11-23 20:03 ` Mattias Engdegård
2021-11-25 9:24 ` Mattias Engdegård
0 siblings, 2 replies; 8+ messages in thread
From: Philip Kaludercic @ 2021-11-23 18:14 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: Daniel Martín, 51882
Mattias Engdegård <mattiase@acm.org> writes:
> Would it be possible to see a full example, with context, of the message emitted by GCC?
> I would like to understand what, exactly, this regexp is supposed to
> be parsing. I've simplified the regexp in compile.el a little but want
> to be sure that I'm not making any mistakes.
Here is a snippet from a program I was working on:
--8<---------------cut here---------------start------------->8---
board.c:319:13: error: leak of 'move' [CWE-401] [-Werror=analyzer-malloc-leak]
319 | return (int16_t) changed;
| ^~~~~~~~~~~~~~~~~
'place_stone': events 1-2
|
| 387 | place_stone(struct Board *b, enum Stone s, struct Coord c)
| | ^~~~~~~~~~~
| | |
| | (1) entry to 'place_stone'
| 388 | {
| 389 | if (!valid_move(b, s, c)) {
| | ~
| | |
| | (2) following 'false' branch...
|
'place_stone': event 3
|
|board.h:60:21:
| 60 | #define I(b, C) ((C).y * (b)->width + (C).x) /* coord -> index */
| | ~~~^~
| | |
| | (3) ...to here
board.h:61:34: note: in expansion of macro 'I'
| 61 | #define stone_at(b, c) (b->board[I(b, c)])
| | ^
board.c:393:6: note: in expansion of macro 'stone_at'
| 393 | stone_at(b, c) = s;
| | ^~~~~~~~
|
'place_stone': event 4
|
| 395 | return update_board(b, c);
| | ^~~~~~~~~~~~~~~~~~
| | |
| | (4) calling 'update_board' from 'place_stone'
|
+--> 'update_board': events 5-8
--8<---------------cut here---------------end--------------->8---
Notice how the
--8<---------------cut here---------------start------------->8---
|board.h:60:21:
--8<---------------cut here---------------end--------------->8---
wouldn't be matched correctly using the previous regexp.
For reference, this is my GCC version:
gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
Philip Kaludercic
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-11-25 9:24 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-11-15 23:13 bug#51882: Handle GCC's -fanalyzer output in M-x compile Philip Kaludercic
2021-11-16 8:13 ` Lars Ingebrigtsen
2021-11-16 10:28 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-17 20:21 ` Philip Kaludercic
2021-11-23 15:35 ` Mattias Engdegård
2021-11-23 18:14 ` Philip Kaludercic
2021-11-23 20:03 ` Mattias Engdegård
2021-11-25 9:24 ` Mattias Engdegård
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.