unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* 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	[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

* bug#51882: Handle GCC's -fanalyzer output in M-x compile
  2021-11-23 18:14   ` Philip Kaludercic
@ 2021-11-23 20:03     ` Mattias Engdegård
  2021-11-25  9:24     ` Mattias Engdegård
  1 sibling, 0 replies; 8+ messages in thread
From: Mattias Engdegård @ 2021-11-23 20:03 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: Daniel Martín, 51882

23 nov. 2021 kl. 19.14 skrev Philip Kaludercic <philipk@posteo.net>:

> Here is a snippet from a program I was working on:

Thank you! I was worried about whether there could be more than one vertical bar preceding the file name and whether the bar could be preceded by something other than spaces. The answers appear to be probably not (but we need to look closer to be sure), and no (from looking at the GCC sources).

This means that the regexp can be further simplified and there is no need to make concessions for multiple vertical lines messing things up for the time being.






^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#51882: Handle GCC's -fanalyzer output in M-x compile
  2021-11-23 18:14   ` Philip Kaludercic
  2021-11-23 20:03     ` Mattias Engdegård
@ 2021-11-25  9:24     ` Mattias Engdegård
  1 sibling, 0 replies; 8+ messages in thread
From: Mattias Engdegård @ 2021-11-25  9:24 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: 51882-done, Daniel Martín

We seem to be done here. Closing.






^ 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 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).