[Bug c/114423] Incorrectly placed caret in the message about expanded _Pragma

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

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

Lewis Hyatt <lhyatt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lhyatt at gcc dot gnu.org

--- Comment #2 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
libcpp is unfortunately not equipped to get valid locations when it lexes from
a _Pragma string. (It thinks it is lexing from a file as normal.) The locations
are wrong even without macros involved. The current situation is that we
produce invalid locations (that happen to usually be close to reasonable,
without macros, although they will be off by a few columns usually) for all the
tokens, then after lexing the tokens, we replace all of their locations with
the (valid) location of the _Pragma operator. This is good enough to make
_Pragma("GCC diagnostic") work and do the right thing (after many bug fixes
over the years), which has been the primary focus. But it means that any
diagnostics generated by libcpp during lexing itself have bad locations.

I submitted a rather large patch series a couple years ago that fixed it
comprehensively. The bulk of it is that the line_map class needs to be able to
handle locations for data that exist in memory and not in any file. Then all
code that uses line_map locations and all diagnostics code needs to be aware of
that concept and support it. The thread was left off here, for reference:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628290.html with the last
full patchset I sent being at
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626885.html. It worked
fine then, however a lot of interfaces have been changed since that time, and
so it would need to be rebased extensively now.

FWIW, with the above-linked patch series, on this example we output:
======
In buffer generated from t.cpp:1:
<generated>:1:11: error: message
    1 | GCC error "message"
      |           ^~~~~~~~~
t.cpp:1:1: note: in <_Pragma directive>
    1 | _Pragma("GCC error \"message\"")
      | ^~~~~~~
In buffer generated from t.cpp:6:
<generated>:1:11: error: message
    1 | GCC error "message"
      |           ^~~~~~~~~
t.cpp:4:1: note: in <_Pragma directive>
    4 | _Pragma("GCC error \"message\"")
      | ^~~~~~~
t.cpp:6:1: note: in expansion of macro ‘err’
    6 | err
      | ^~~
======

I am not sure why I stopped getting responses to that patch series. I was
disinclined to ping it further because I worried that it was perhaps deemed too
large and invasive, to fix what ends up being a rather minor problem in
practice? I think it would be doable to handle it with a more incremental
approach... we could at least achieve that diagnostics generated during lexing
get assigned to the valid location of the _Pragma operator instead of an
invalid one.