http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252
--- Comment #9 from dodji at seketeli dot org <dodji at seketeli dot org>
2012-11-19 17:05:57 UTC ---
"manu at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> a écrit:
> 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:
<built-in>: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
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?
