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?
