[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

["manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #18 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #17)
> It would be less of a pain if -Wsystem-headers caused both locations to be
> printed, but it doesn't, so sometimes the only option is to dump the
> preprocessed source without line markers and then compile that to get two
> locations, then map the location in the preprocessed source back to a line
> in the original source.

You could try with this:

Index: tree-diagnostic.c
===================================================================
--- tree-diagnostic.c   (revision 220306)
+++ tree-diagnostic.c   (working copy)
@@ -197,12 +197,14 @@ maybe_unwind_expanded_macro_loc (diagnos
           within a system header.  */
         const struct line_map *m = NULL;
         source_location l =
           linemap_resolve_location (line_table, resolved_def_loc,
                                     LRK_SPELLING_LOCATION,  &m);
-        if (l < RESERVED_LOCATION_COUNT || LINEMAP_SYSP (m))
-          continue;
+        if (l < RESERVED_LOCATION_COUNT)
+         continue;
+       if (LINEMAP_SYSP (m) && !context->dc_warn_system_headers)
+         continue;

        /* We need to print the context of the macro definition only
           when the locus of the first displayed diagnostic (displayed
           before this trace) was inside the definition of the
           macro.  */

.. but I still not see why we need to skip system-headers at all. The comment
in the original patch (r186970)

I am then using that facility in the diagnostics printing module and
in the macro unwinder to avoid printing diagnostics lines that refer
to the locations for built-ins or more generally for reserved
locations.  Note that when I start the dance of skipping a built-in
location I also skip locations that are in system headers, because it
turned out that a lot of those built-ins are actually used in system
headers (e.g, "#define INT_MAX __INT_MAX__" where __INT_MAX__ is a
built-in).

suggests that we do not want to give a note for the #define, but it seems a
small price to pay for getting the other cases right.
>From gcc-bugs-return-475725-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Feb 01 20:35:46 2015
Return-Path: <gcc-bugs-return-475725-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15539 invoked by alias); 1 Feb 2015 20:35:46 -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 15493 invoked by uid 48); 1 Feb 2015 20:35:43 -0000
From: "max at cert dot cx" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/61601] C++11 regex resource exhaustion
Date: Sun, 01 Feb 2015 20:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: max at cert dot cx
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61601-4-8zpdB2tW4Z@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61601-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61601-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-02/txt/msg00058.txt.bz2
Content-length: 206

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

--- Comment #6 from Maksymilian Arciemowicz <max at cert dot cx> ---

> Do you have any other testcases?

for trunk? maybe you have to use ::regex_match