[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #13 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-05-10 09:57:55 UTC --- 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.
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-12-24 23:14 --- 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. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #11 from esigra at gmail dot com 2008-09-21 20:38 --- 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]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-09-03 02:42 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #9 from manu at gcc dot gnu dot org 2008-05-08 10:44 --- (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. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC|manu at gcc dot gnu dot org | Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #7 from manu at gcc dot gnu dot org 2008-05-07 10:06 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #8 from esigra at gmail dot com 2008-05-07 13:08 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #4 from esigra at gmail dot com 2008-05-06 18:00 --- (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? -- esigra at gmail dot com changed: What|Removed |Added CC||esigra at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-06 18:21 --- But seriously colorization should not be done in the compiler. Just like IDE should not be part of the compiler ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #6 from esigra at gmail dot com 2008-05-06 18:47 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #3 from manu at gcc dot gnu dot org 2007-05-18 14:16 --- 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 -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-18 01:13 --- Alternatively, or in combination, gcc could provide references to more widely-available sources (such as KR and HS 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #2 from fang at csl dot cornell dot edu 2007-05-18 03:27 --- 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 -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
