[Bug preprocessor/114423] New: Incorrectly placed caret in the message about expanded _Pragma

[Bug preprocessor/114423] New: Incorrectly placed caret in the message about expanded _Pragma

[centurionn009 at gmail dot com]

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

            Bug ID: 114423
           Summary: Incorrectly placed caret in the message about expanded
                    _Pragma
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: centurionn009 at gmail dot com
  Target Milestone: ---

Created attachment 57762
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57762&action=edit
test

Diagnostics working with _Pragma from macro puts a caret in position same as
directly inside the macro.
```
_Pragma("GCC error \"message\"")

#define err \
_Pragma("GCC error \"message\"")

err
```

gcc -E:
<source>:1:11: error: message
    1 | _Pragma("GCC error \"message\"")
      |           ^~~~~~~~~
<source>:6:11: error: message
    6 | err
      |           ^

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-03-21
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |diagnostic
          Component|preprocessor                |c

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

clang produces:
```
<source>:2:1: error: message
    2 | _Pragma("GCC error \"message\"")
      | ^
<scratch space>:2:6: note: expanded from here
    2 |  GCC error "message"
      |      ^
<source>:7:1: error: message
    7 | err
      | ^
<source>:4:13: note: expanded from macro 'err'
    4 | #define err \
      |             ^
<scratch space>:4:6: note: expanded from here
    4 |  GCC error "message"
      |      ^
```

I wonder if GCC is doing something similar to get the column info and then
still using the original line.

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

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