This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]