[Bug c++/65448] New: Allow for cascade includes in error messages

[Bug c++/65448] New: Allow for cascade includes in error messages

[ethouris at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65448

            Bug ID: 65448
           Summary: Allow for cascade includes in error messages
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ethouris at gmail dot com

When gcc reports a compile error that refers to a line in a file that is
included by another include file, which is finally included by the *.cpp file
being compiled, it reports the error more-less this way:

In file included from file1.h:10:1,
                 from file2.h:11:1,
                 from file.cpp:9:0:
file3.h:25:0: error: 'symbol' does not name a type

Most tools that use these error reports simply skip the first three lines, as
they do not look like "standard compiler error format". It would be nice to
have at least an option to change the format into something like this:

file1.h:10:1: note: In file included from here,
file2.h:11:1: note: from here,
file.cpp:9:0: note: from here,
file3.h:25:0: error: 'symbol' does not name a type

Some programming mistakes are very tough to determine without the cascade
include information (such as forgetting a semicolon in some declaration before
an #include directive).

[Bug c++/65448] Allow for cascade includes in error messages

[ethouris at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65448

--- Comment #2 from Michal Malecki <ethouris at gmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #1)

> Which tools? Shouldn't those tools be fixed instead? 

The problem is that it's very easy to interpret the format that every line
matches:

<filename>:<line>[:<column>]: <error message>

This is generally understood by all tools, and it's a format that can be also
easily generated. This is a simple and general rule that can be claimed across
the tools and it has been used as an informal standard since always. Anything
that doesn't match this format is generally treated as "to be ignored" or
simply "not a compiler error message" (for example, an echoed command line from
make). These lines starting with "In file included from" do not undergo any
stable format definition and are not easy parseable, especially if we regard
that the message isn't necessarily in English.

> Perhaps this would have been a better way to do it (although I would prefer
> the notes after the error, and it could just not say "note:", to be
> consistent with what we do for template instantiations),

Whatever. I just gave this as an example - at least be it something that
matches the above format.

> if we could start over again, but now GCC has always behaved like this,

So you can imagine how sick and tired some are :D

Actually I'm using gcc since about 2.6 version and I cannot recall any tool
that understands these "In file included from" messages.

> if we change it, it may break other tools.

Should there be any - but even if, I think I spoke about "having an option to
change the format". I meant command-line option to change the behavior, while
leaving the default behavior as is, should that not be clear enough. Just like
there's for example a -fmessage-length option.

BTW. If I'm not mistaken, there are more cases, when error messages from the
compiler may be interesting, but they don't match the error message format and
are therefore skipped by the tools.
>From gcc-bugs-return-481840-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Mar 26 15:12:39 2015
Return-Path: <gcc-bugs-return-481840-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21539 invoked by alias); 26 Mar 2015 15:12:38 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 21492 invoked by uid 48); 26 Mar 2015 15:12:35 -0000
From: "rainer@emrich-ebersheim.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65581] [5 Regression] testsuite lto issue: multiple definition of `main', undefined reference to `WinMain'
Date: Thu, 26 Mar 2015 15:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rainer@emrich-ebersheim.de
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65581-4-RZ3iNAhtxB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65581-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65581-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg02984.txt.bz2
Content-length: 588

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide581

--- Comment #5 from Rainer Emrich <rainer@emrich-ebersheim.de> ---
(In reply to Kai Tietz from comment #4)
> This issue is related to building of crt. so it doesn't have something to do
> with gcc's lto in first hand.

That leaves the question, why on earth is this only exposed by current trunk?
I did a quick check. The issue is present on trunk with all mingw-w64 runtimes
I tested, back to October last year. OTOH 4.9.2 and 4.8.4 are fine with my
current mingw-w64 runtime.

So, what's the issue? I'm a little bit nervous.

Rainer

[Bug c++/65448] Allow for cascade includes in error messages

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65448

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
> Actually I'm using gcc since about 2.6 version and I cannot recall any tool
> that understands these "In file included from" messages.

Emacs has always handled them.

[Bug c++/65448] Allow for cascade includes in error messages

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65448

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Michal Malecki from comment #2)
> (In reply to Manuel López-Ibáñez from comment #1)
> 
> > Which tools? Shouldn't those tools be fixed instead? 
> 
> The problem is that it's very easy to interpret the format that every line
> matches:
> 
> <filename>:<line>[:<column>]: <error message>

Taking into account that filename can have spaces, it actually does match the
format with <filename>=In file included from x.c

Emacs, for example, can parse those lines and open the correct file and
location.

> command line from make). These lines starting with "In file included from"
> do not undergo any stable format definition and are not easy parseable,
> especially if we regard that the message isn't necessarily in English.

The language problem exists also with the error/warning/note lines (PR19165).
The only way to fix it is to emit something that is designed to be parsed by
machines, some kind of structured format. But of course, first tools have to
agree on which format they want to parse.

> > Perhaps this would have been a better way to do it (although I would prefer
> > the notes after the error, and it could just not say "note:", to be
> > consistent with what we do for template instantiations),
> 
> Whatever. I just gave this as an example - at least be it something that
> matches the above format.

I'm just pointing out ways in which a new alternative could be argued for. You
could also use http://www.gnu.org/prep/standards/standards.html#Errors as an
argument.

In any case, someone would need to argue convincingly in favour of it AND
implement it. I don't think any existing GCC devs will divest their time to
implement this, thus you need to convince someone new (or do it yourself).

https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

and: https://gcc.gnu.org/wiki/Community in particular, points 4 and 5.
>From gcc-bugs-return-481844-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Mar 26 15:41:40 2015
Return-Path: <gcc-bugs-return-481844-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 86065 invoked by alias); 26 Mar 2015 15:41:40 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 86010 invoked by uid 48); 26 Mar 2015 15:41:37 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace
Date: Thu, 26 Mar 2015 16:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: accepts-invalid, rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to
Message-ID: <bug-59256-4-twnhx215xK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59256-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59256-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg02988.txt.bz2
Content-length: 915

https://gcc.gnu.org/bugzilla/show_bug.cgi?idY256

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|jason at gcc dot gnu.org           |unassigned at gcc dot gnu.org

--- Comment #4 from Jason Merrill <jason at gcc dot gnu.org> ---
A related testcase:

inline namespace A {
  void f();
}

class B
{
  B();
  friend void ::f();
};

void A::f() { B b; }

int main()
{
  f();
}

It turns out that friend matching code doesn't support inline namespaces very
thoroughly.  set_decl_namespace handles this sort of thing for some cases, but
it punts on templates and then tsubst_friend_function doesn't do anything about
inline namespaces.

But this is too complicated to fix for GCC 5, so I'm unassigning myself.

[Bug c++/65448] Allow for cascade includes in error messages

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65448

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I was going to suggest to use json diagnostic format
(-fdiagnostics-format=json) with newer GCC but I noticed it does not output the
header include stack (which I filed as PR 107941 ).