https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65448
--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Michal Malecki from comment #2) > (In reply to Manuel López-Ibáñez from comment #1) > > > Which tools? Shouldn't those tools be fixed instead? > > The problem is that it's very easy to interpret the format that every line > matches: > > <filename>:<line>[:<column>]: <error message> Taking into account that filename can have spaces, it actually does match the format with <filename>=In file included from x.c Emacs, for example, can parse those lines and open the correct file and location. > command line from make). These lines starting with "In file included from" > do not undergo any stable format definition and are not easy parseable, > especially if we regard that the message isn't necessarily in English. The language problem exists also with the error/warning/note lines (PR19165). The only way to fix it is to emit something that is designed to be parsed by machines, some kind of structured format. But of course, first tools have to agree on which format they want to parse. > > Perhaps this would have been a better way to do it (although I would prefer > > the notes after the error, and it could just not say "note:", to be > > consistent with what we do for template instantiations), > > Whatever. I just gave this as an example - at least be it something that > matches the above format. I'm just pointing out ways in which a new alternative could be argued for. You could also use http://www.gnu.org/prep/standards/standards.html#Errors as an argument. In any case, someone would need to argue convincingly in favour of it AND implement it. I don't think any existing GCC devs will divest their time to implement this, thus you need to convince someone new (or do it yourself). https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps and: https://gcc.gnu.org/wiki/Community in particular, points 4 and 5.
