[Bug c/52952] Wformat location info is bad (wrong column number)

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952

--- Comment #10 from Manuel LÃpez-IbÃÃez <manu at gcc dot gnu.org> 2012-05-24 19:05:26 UTC ---
(In reply to comment #9)
> "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> a Ãcrit:
> 
> > So either one keeps track of all source locations of all "interesting"
> > characters within strings, which sounds infeasible. Or one needs to
> > re-preprocess the format string, creating new locations on-the-fly. Dodji, is
> > this possible?
> 
> With the current infrastructure, I fear we cannot re-process the format
> string *after* the initial pre-processing phase is done, to create new
> locations that we'd a in the line maps.

Could you elaborate on the reasons for this? Is it impossible to create new
locations on the fly? 

As a brute-force approach, we at least should be able to re-preproces the whole
file, no? Could we do this by invoking libcpp directly rather than calling a
command? 

> Does that make sense?

This implies that the diagnostics code would need to handle a byte offset, no? 

And I am not sure this will handle well the case of split strings and macro
expansion, like Clang does.