[Bug c/52952] Wformat location info is bad (wrong column number)
manu at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Fri May 25 14:18:00 GMT 2012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #12 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-05-25 14:09:00 UTC ---
>
> Basically, the current encoding of the map requires that a new location
> encoding in a map must always be the last location of that map. You
> cannot insert a location in the "middle" of an existing map.
Just continuing with the thought-experiment... would it be possible to
duplicate the current line-table, then start re-encoding locations from the
last location before the interesting character, and simply stop when the
interesting character is reached? Then switch line-tables on the fly before
giving the diagnostic, and switch back to the original line-table after it.
I guess Clang has a different encoding for source locations, because it seems
they are generating new location indexes on the fly.
> I guess that would take re-processing the whole compilation unit,
> starting from the location map that you have changed. And, just handling
> locations wouldn't be enough, we'd need to basically re-tokenize the
> files that are re-processed, because the locations are primarily carried
> by instances of cpp_token, and we need the locations of these tokens to
> be updated.
>
> That doesn't seem practical.
Practical because of complexity, ugliness or computation time?
> > And I am not sure this will handle well the case of split strings and macro
> > expansion, like Clang does.
>
> Yeah. Which makes me think that maybe we might want to introduce a new
> way to represent string literal tokens in libcpp, that keeps the
> underlying raw format. There would be a character oriented iterator API
> for that string literal representation. And that iterator API could
> provide its user with the file/line/column information for the current
> character. And one could pass any such iterator to some of the
> diagnostic routines.
This sounds interesting, but I still do not understand how it can handle macro
expansions. Could you elaborate?
More information about the Gcc-bugs
mailing list