GNU bug report logs - #51882
Handle GCC's -fanalyzer output in M-x compile

Previous Next

Package: emacs;

Reported by: Philip Kaludercic <philipk <at> posteo.net>

Date: Mon, 15 Nov 2021 23:14:02 UTC

Severity: normal

Tags: patch

Done: Mattias Engdegård <mattiase <at> acm.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51882 in the body.
You can then email your comments to 51882 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#51882; Package emacs. (Mon, 15 Nov 2021 23:14:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Philip Kaludercic <philipk <at> posteo.net>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 15 Nov 2021 23:14:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Handle GCC's -fanalyzer output in M-x compile
Date: Mon, 15 Nov 2021 23:13:05 +0000
[Message part 1 (text/plain, inline)]
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'

[0001-Improve-error-parsing-for-GCC-fanalyzer-output.patch (text/patch, attachment)]
[Message part 3 (text/plain, inline)]
-- 
	Philip Kaludercic

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51882; Package emacs. (Tue, 16 Nov 2021 08:14:02 GMT) Full text and rfc822 format available.

Message #8 received at 51882 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 51882 <at> debbugs.gnu.org
Subject: Re: bug#51882: Handle GCC's -fanalyzer output in M-x compile
Date: Tue, 16 Nov 2021 09:13:41 +0100
Philip Kaludercic <philipk <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51882; Package emacs. (Tue, 16 Nov 2021 10:29:02 GMT) Full text and rfc822 format available.

Message #11 received at 51882 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 51882 <at> debbugs.gnu.org
Subject: Re: bug#51882: Handle GCC's -fanalyzer output in M-x compile
Date: Tue, 16 Nov 2021 11:28:06 +0100
Philip Kaludercic <philipk <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51882; Package emacs. (Wed, 17 Nov 2021 20:22:02 GMT) Full text and rfc822 format available.

Message #14 received at 51882 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 51882 <at> debbugs.gnu.org
Subject: Re: bug#51882: Handle GCC's -fanalyzer output in M-x compile
Date: Wed, 17 Nov 2021 20:21:00 +0000
Daniel Martín <mardani29 <at> yahoo.es> writes:

> Philip Kaludercic <philipk <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51882; Package emacs. (Tue, 23 Nov 2021 15:36:02 GMT) Full text and rfc822 format available.

Message #17 received at 51882 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 51882 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: bug#51882: Handle GCC's -fanalyzer output in M-x compile
Date: Tue, 23 Nov 2021 16:35:39 +0100
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.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51882; Package emacs. (Tue, 23 Nov 2021 18:15:01 GMT) Full text and rfc822 format available.

Message #20 received at 51882 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 51882 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#51882: Handle GCC's -fanalyzer output in M-x compile
Date: Tue, 23 Nov 2021 18:14:38 +0000
Mattias Engdegård <mattiase <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51882; Package emacs. (Tue, 23 Nov 2021 20:04:02 GMT) Full text and rfc822 format available.

Message #23 received at 51882 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 51882 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#51882: Handle GCC's -fanalyzer output in M-x compile
Date: Tue, 23 Nov 2021 21:03:51 +0100
23 nov. 2021 kl. 19.14 skrev Philip Kaludercic <philipk <at> 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.





Reply sent to Mattias Engdegård <mattiase <at> acm.org>:
You have taken responsibility. (Thu, 25 Nov 2021 09:25:01 GMT) Full text and rfc822 format available.

Notification sent to Philip Kaludercic <philipk <at> posteo.net>:
bug acknowledged by developer. (Thu, 25 Nov 2021 09:25:01 GMT) Full text and rfc822 format available.

Message #28 received at 51882-done <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 51882-done <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#51882: Handle GCC's -fanalyzer output in M-x compile
Date: Thu, 25 Nov 2021 10:24:37 +0100
We seem to be done here. Closing.





bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 23 Dec 2021 12:24:09 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 86 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.