As a supplement to the -- by necessity -- terse error messages generated by gcc, it would be fantastic (IMHO) if a new option could be added to gcc to display the current language standard along with the _section_ in that standard that the error applies to. IE, rather than... hello.c:1:10: error: #include expects "FILENAME" or <FILENAME> We could have: hello.c:1:10:c99:1.2.3.4: error: #include expects "FILENAME" or <FILENAME> Where section 1.2.3.4 in the c99 standard might explain the syntax of includes. This isn't a particularly good example, but some of gcc's warning and error messages are cryptic enough that a pointer to the actual language specification could be very useful for some people. Alternatively, or in combination, gcc could provide references to more widely-available sources (such as K&R and H&S for C, and Stroustrup or the ARM for C++ for example). As another alternative, how about referencing gcc test cases to help the developer understand the problem? Thanks for reading. James.
> Alternatively, or in combination, gcc could provide references to more > widely-available sources (such as K&R and H&S for C, and Stroustrup or the ARM > for C++ for example). Except those are very unofficial when it comes to a standard and usually don't match the standard any more. Can you show one example of a terse error message? Since the #include you showed is very self explainitory at least I think.
<wishfulthinking> It's too bad the holy standard documents (ISO/IEC) aren't free or freely distributable, they could be nice supplementary reference material to go along with a compiler, even one that isn't perfectly standard adhering (yet). </wishfulthinking>
I see several reasons for not doing this: 1) External tools expect the current output format. Your proposal will break that. 2) Standards are not freely distributable, thus they are not widely available. 3) Getting the extra text (testcases, examples, etc) right seems even more complex than getting the original message right. 4) Given the effort-benefit ratio, I don't see many GCC developers jumping into this. Nevertheless, as Andrew points out, we would rather correct cryptic diagnostics. Whenever you find one, you could open a bug report for it. We already have similar bug reports (see PR 29062). Finally, if you still think it is worth it, you could implement it yourself as a wrapper to the output of GCC (similar to how colorgcc [*] works). Parse the output of GCC, match diagnostic messages, and depending on the matched message, write whatever text you think would be appropriate. Much easier than hacking GCC itself and it will give an idea on how difficult the task actually is and how many people would be actually interested on it. [*] http://packages.debian.org/unstable/devel/colorgcc.html
(In reply to comment #3) > 2) Standards are not freely distributable, thus they are not widely available. You say that as if it was a general fact, but it is certainly not. For example the Ada reference manual is available right here: [http://www.ada-auth.org/arm.html] More correct would be to say that *some* standards are not widely available. > Finally, if you still think it is worth it, you could implement it yourself as a wrapper to the output of GCC (similar to how colorgcc [*] works). You must mean similar to how colorgcc *not* works. colorgcc is just an ugly hack that should be scrapped and burned as soon as GCC is fixed to format its own output properly. What colorgcc tries to do is total nonsense. It tries to parse localized output! Of course it fails for 94% of the supported languages (only English sort-of works as far as I know). Even English may fail if there is a version mismatch. And seriously, what is more efficent, adding a colour code sequence to the string constant in GCC that says "warning:" or having separate scripts for each combination of locale and GCC version, that parse the output of GCC and recreates it with colour codes? What would distributions prefer to maintain?
But seriously colorization should not be done in the compiler. Just like IDE should not be part of the compiler ...
(In reply to comment #5) > But seriously colorization should not be done in the compiler. Just like IDE > should not be part of the compiler ... Colorization of a message is part of the message. It should obviously be done whereever the message is constructed. (IDE has nothing to do with this.) With your argument, the compiler should not do text messages (or any localization thereof) either, but rather return some code that an external program formats/localizes and presents to the user in a suitable way.
(In reply to comment #6) > Colorization of a message is part of the message. It should obviously be done > whereever the message is constructed. (IDE has nothing to do with this.) With > your argument, the compiler should not do text messages (or any localization > thereof) either, but rather return some code that an external program > formats/localizes and presents to the user in a suitable way. Actually, that doesn't sound too bad. It will probably help to embed GCC in IDEs and other customizations. But I digress... Adding color output (ala ls --color) or the proposal in this bug (gcc as a lecturer in programming) show a critical misunderstanding: Assuming that GCC developers are bored and have nothing to do. There are many many features that GCC developers themselves would like to see implemented and they are not because of lack of time. Therefore, people coming up with random half-backed ideas, which they do not intend to fully specify, much less implement, is hopeless. Honestly, GCC is free software. Anyone can implement whatever they want. We gave you our reasons why we think this is a bad idea. Prove us wrong by writing the code (or finding someone to write it for you). If it is indeed a good idea, distributions and users will pick it up and that will show that developers should change their minds and include it in the original source code.
(In reply to comment #7) > Adding color output (ala ls --color) or the proposal in this bug (gcc as a > lecturer in programming) show a critical misunderstanding: Assuming that GCC > developers are bored and have nothing to do. There are many many features that > GCC developers themselves would like to see implemented and they are not > because of lack of time. Therefore, people coming up with random half-backed > ideas, which they do not intend to fully specify, much less implement, is > hopeless. Sorry, you got it totally wrong! When someone suggests a feature that he thinks would be useful, he does definitely not imply that the current developers are bored and have nothing to do. The critical misunderstanding here is that some GCC developers think that a feature request is something that they are obliged to implement within a certain time and the only way to get rid of that obligation is to dismiss any idea, that they do not have time to implement right now, as invalid. We are developers too for various projects and we get feature requests all the time. Many of the ideas that we get are useful but there is no way that we can implement them all within the foreseeable future. Still we do not rush to dismiss ideas as invalid. And we certainly do not misconceieve it as implications that we are bored or do not have any ideas of our own. I think the criterion for closing feature requests as invalid should be modified from "we do not have time to implement this feature any time soon" to "there is no way that this feature would be useful". This is how most projects handle it and what reporters interpret it as.
(In reply to comment #8) > > Sorry, you got it totally wrong! When someone suggests a feature that he thinks > would be useful, he does definitely not imply that the current developers are > bored and have nothing to do. If after being repetitively told that the developers don't see a feature request as appropriate or useful or even practical such someone keeps insisting and arguing giving the impression that such person is offended because his/her feature doesn't get any attention, then, at least in my case, my conclusion is that such person thinks that the developers should go out of their way to precisely define and implement the feature in his/her behalf. Sorry, if that is not the case here. > The critical misunderstanding here is that some GCC developers think that a > feature request is something that they are obliged to implement within a > certain time and the only way to get rid of that obligation is to dismiss any > idea, that they do not have time to implement right now, as invalid. That is obviously not the case. There are many interesting feature requests open in bugzilla that most GCC developers would like to see implemented but nobody has had time to implement right now. On the other hand, as far as I understand it, features marked as invalid won't be implemented ever. Not even if the developers had time to implement them. The reasons maybe several: not useful, not appropriate for the scope of the project, not possible. We just want to keep our bugzilla as clean and useful as possible while not giving false hopes to users. Some of us have argued above that this PR doesn't meet some of the above criteria. Anyway, this discussion is pointless. This PR won't be closed as INVALID. If you are happier if we keep open this feature request, so be it.
for warnings, we do provide (in most cases) the option that enables/disables the warning. But I don't see this happening any time soon, if ever.
I found that James' wish is already implemented in some cases: $ strings /usr/i686-pc-linux-gnu/gnat-gcc-bin/4.2/gnat|grep "RM " illegal use of remote access-to-class-wide type, see RM E.4(18) A user that gets that error message can look it up at for example [http://www.adacore.com/multimedia/Ada2005_RM_HTML/RM-E-4.html].
This is not useful as sometimes it is hard to point out the one C99/C++98 which tells you why your code is invalid, in some cases you need to point to 3 different locations in the standard and read that. An example comes from template lookup rules.
I have come around on this issue (and the color output). I now think it would be useful to have an extra verbose mode. It is clear it won't be implemented by existing GCC devs and probably it won't be accepted in mainline GCC, so it will have to be a plugin. The first step is to have a significant number of verbose descriptions. I have started a list but it needs a lot more contributions: http://gcc.gnu.org/wiki/VerboseDiagnostics The second step would be to enable plugins to intercept warning/error messages and add their own actions (in this case, just printing the verbose output). Even if nobody bothers to finish this second step, the list itself would be helpful.