From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26423 invoked by alias); 19 Nov 2012 17:06:20 -0000 Received: (qmail 25724 invoked by uid 55); 19 Nov 2012 17:05:58 -0000 From: "dodji at seketeli dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header Date: Mon, 19 Nov 2012 17:06:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: dodji at seketeli dot org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg01791.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D55252 --- Comment #9 from dodji at seketeli dot org 2= 012-11-19 17:05:57 UTC --- "manu at gcc dot gnu.org" a =C3=A9crit: > Hum, I am not sure why the macro unwinder avoids unwinding if the > macro comes from a system-header. If a warning message comes from a > system-header, then it should have been suppressed earlier and never > reach the macro unwinder. Otherwise, we already have emitted the > diagnostic, so the macro unwinder just provides more context. Yeah. I agree this is weird. There are cases where the spelling location is in normal main file, but some locations in its macro expansion context are e.g, for built-in tokens. In that case we can get ugly diagnostic prefixes like: :0:0: warning: conversion to 'float' alters 'int' constant value This is what the commit r186970 tries to fix. Please read the commit log (that contains useful information about the context of the bug, besides the ChangeLog that we like to put in there) of that revision to understand why we are skipping each locus that comes from a system header too. I guess a way to handle this is to=20 1/ make the macro unwinder call linemap_unwind_to_first_non_reserved_loc at the beginning of the unwind process and start unwinding from there 2/ during the rest of the unwind process, dismiss reserved locations only. Not those coming from system headers. Would this make sense?