From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7C1C43858C32; Fri, 22 Mar 2024 14:48:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7C1C43858C32 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1711118937; bh=Sd72qMn5lBbLMwEf/qEq+S3XAOFgasAuY+Vbzd3+mlY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=rr3EZ9m0oV4cn+ugn/DKq/rPHN0epogAjv/mbEkJg4eCBPb3l2BxUHji7AIs9nD+Y znFhD735UmdMagReb+UkeBMRZhyfOQccUNfQgNMah4MRb81lrBoN5C+7Ii2IQcKCSu YvQw33R4Jb2LQ0QbCIYRjI2jVyG0CbOLO5D+QZYw= From: "lhyatt at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/114423] Incorrectly placed caret in the message about expanded _Pragma Date: Fri, 22 Mar 2024 14:48:56 +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: 14.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: lhyatt at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: 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: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114423 Lewis Hyatt changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lhyatt at gcc dot gnu.org --- Comment #2 from Lewis Hyatt --- libcpp is unfortunately not equipped to get valid locations when it lexes f= rom a _Pragma string. (It thinks it is lexing from a file as normal.) The locat= ions 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 awar= e 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, a= nd so it would need to be rebased extensively now. FWIW, with the above-linked patch series, on this example we output: =3D=3D=3D=3D=3D=3D In buffer generated from t.cpp:1: :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: :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 =E2=80=98err=E2=80=99 6 | err | ^~~ =3D=3D=3D=3D=3D=3D 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 lex= ing get assigned to the valid location of the _Pragma operator instead of an invalid one.=