[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 at gcc dot gnu dot 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.