> I never ran the patch through the test suite. I assume it would require > some test suite changes.
OK, I can do that and see where things are. > Also, I've experimented more with Aldy's location improvement patch > (which is now on mainline, I think diagnostics-branch is closed), and > Emacs (I used Emacs 23 for my experiment -- automated code rewriting > using gcc error messages to decide where to edit) agrees with what GCC > generates now. So, changing this might actually be the wrong thing to > do now. Well, I guess it's a chicken and egg problem: Emacs might have been modified to follow whatever GCC is outputting right now (even though it's not following GNU standard). Since the addition of columns and in particular enabling of columns by default is pretty recent, I think it still makes sense to make this change, otherwise later might indeed be too late. Alternatively we could have an option, but that would be overkill IMO. > If you're interested in locations, I have a couple other unfinished > location patches that could use some attention. One is an attempt to > fix all the errors in libcpp to use the correct location. The other is > a patch to include macro expansion information in a location_t. I'm working on generating cross-ref info from GCC for C/C++ sources. So I'm not too interested directly in error location (your first patch above), but the second patch you mention might be of interest indeed, can you please send it to me? I'm not sure I understand what 'include macro expansion info in a location_t' means exactly, so I'm curious. Also, what about column info in libcpp itself, in particular when handling macros? It seems that when e.g. the define() or used_define() callbacks are called, the only useful sloc info stored in input_location (itself kind of deprecated as I understand it) is the current line, with column 0. Might actually be related to your first patch mentioned above? Arno
