Compiler error and warning messages are sometimes difficult to understand - especially (but not exclusively) for novice developers. They are also typically concise, and assume some knowledge of relevant terms, which the program author may not know, despite being able to write a program. I also note that many users repeatedly ask questions on web forums and Q&A sites (e.g. StackOverflow) regarding specific error messages they get - not just asking "what's wrong with my code which causes the error?", but rather "What does this message mean? I don't understand what it says." Now, the GCC manual does not seem include such a listing, and I could not find it on the Wiki either. Assuming it indeed doesn't exist - I believe that it should. If it does exist, then the bug is that it's difficult to notice/locate. Note that to realize such a listing it should be possible to harness more than just the GCC developers, if it's done through the Wiki. (Of course people would need to be attracted to the Wiki to assist in doing this.)
We try to improve error messages rather than list all of the error messages out. For an example the following URL links of the improvements to all of the diagnostic in GCC 8 (that was recorded as a bugzilla entry): https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&component=c%2B%2B&keywords=diagnostic%2C%20&keywords_type=allwords&list_id=210084&product=gcc&query_format=advanced&resolution=FIXED&short_desc=Regression&short_desc_type=notregexp&target_milestone=8.0
(In reply to Andrew Pinski from comment #1) > We try to improve error messages rather than list all of the error messages > out. But the listed error messages must balance readability/accessibility with conciseness. Specifically, an error message will never have a short example of a typical error and a correction. Or an explanation, in a few sentences, of a some concept referred to by the message, or a quotation of a paragraph from the language standard and so on.
(In reply to Eyal Rozenberg from comment #0) > Now, the GCC manual does not seem include such a listing, and I could not > find it on the Wiki either. Assuming it indeed doesn't exist - I believe > that it should. If it does exist, then the bug is that it's difficult to > notice/locate. There's https://gcc.gnu.org/wiki/VerboseDiagnostics for a few such errors. > Note that to realize such a listing it should be possible to harness more > than just the GCC developers, if it's done through the Wiki. (Of course > people would need to be attracted to the Wiki to assist in doing this.) This absolutely should be done by users, not the GCC developers. We're all busy working on GCC already, and if we knew how to make the diagnostics easier to understand then we'd already have done it.
(In reply to Jonathan Wakely from comment #3) > There's https://gcc.gnu.org/wiki/VerboseDiagnostics for a few such errors. Well, that's a (tiny) start... however: * I wouldn't have found it if you wouldn't have provided the link - and I did search the Wiki (albeit not very thoroughly) * I think that has low search engine visibility * I believe there should be some auto-generated skeleton of that (either a single page or multiple pages) which collects all error messages. * I would definitely separate the language-specific errors for different languages (perhaps an even finer separation into pages is called for, but certainly at least that) > This absolutely should be done by users, not the GCC developers. We're all > busy working on GCC already, and if we knew how to make the diagnostics > easier to understand then we'd already have done it. Fair enough, but, honestly - if the page says "Please, feel free to suggest new content in gcc-help mailing list" - practically nobody will contribute. Also, I'm sure that some of this could be adapted from from other sources online.
(In reply to Eyal Rozenberg from comment #4) > Fair enough, but, honestly - if the page says "Please, feel free to suggest > new content in gcc-help mailing list" - practically nobody will contribute. Why not? > Also, I'm sure that some of this could be adapted from from other sources > online. Be the change that you want to see in the world. If you want this, make it happen.
(In reply to Jonathan Wakely from comment #3) > (In reply to Eyal Rozenberg from comment #0) > > Now, the GCC manual does not seem include such a listing, and I could not > > find it on the Wiki either. Assuming it indeed doesn't exist - I believe > > that it should. If it does exist, then the bug is that it's difficult to > > notice/locate. > > There's https://gcc.gnu.org/wiki/VerboseDiagnostics for a few such errors. > > > Note that to realize such a listing it should be possible to harness more > > than just the GCC developers, if it's done through the Wiki. (Of course > > people would need to be attracted to the Wiki to assist in doing this.) > > This absolutely should be done by users, not the GCC developers. We're all > busy working on GCC already, and if we knew how to make the diagnostics > easier to understand then we'd already have done it. This is something David Malcolm sometimes focuses on; cc-ing him.
(In reply to Jonathan Wakely from comment #5) > Be the change that you want to see in the world. > > If you want this, make it happen. Well, I already started by filing this bug, but point taken. > (In reply to Eyal Rozenberg from comment #4) > > Fair enough, but, honestly - if the page says "Please, feel free to suggest > > new content in gcc-help mailing list" - practically nobody will contribute. > > Why not? Really? Ok, I'll explain: Many/most people familiar with collaboratively-edited resources such as Wikis or Q&A sites expect either immediate ability to edit content, or a requirement of at most website registration. What this line is telling visitors is (with slight over-dramatization): "Don't expect to be able to edit existing content on this page, ever. Don't expect to easily add content to this page, ever. If you want to even add anything to this page, you have to increase your level of commitment to that of being a mailing list member. You'll have to talk to people on that mailing list. You'll have to convince them your addition is important. Then maybe it'll be added." - this amounts to telling most people to go away.
(In reply to Eyal Rozenberg from comment #7) > (In reply to Jonathan Wakely from comment #5) > > Be the change that you want to see in the world. > > > > If you want this, make it happen. > > Well, I already started by filing this bug, but point taken. So far you're just asking for other people to do the work. Speaking for myself, I already know what GCC's diagnostics mean, and so what you're suggesting wouldn't be useful to me* and that's probably true for most GCC developers. You're asking busy people to do a ton of work. * before you say I should do it anyway to help users, note that I did already add most of the content to the wiki page. > > (In reply to Eyal Rozenberg from comment #4) > > > Fair enough, but, honestly - if the page says "Please, feel free to suggest > > > new content in gcc-help mailing list" - practically nobody will contribute. > > > > Why not? > > Really? Ok, I'll explain: Many/most people familiar with > collaboratively-edited resources such as Wikis or Q&A sites expect either > immediate ability to edit content, or a requirement of at most website > registration. What this line is telling visitors is (with slight > over-dramatization): "Don't expect to be able to edit existing content on > this page, ever. Don't expect to easily add content to this page, ever. If This isn't a slight over-dramatization, this is nonsense. "Please feel free to suggest new content" does not mean "you can not add new content, ever". > you want to even add anything to this page, you have to increase your level > of commitment to that of being a mailing list member. Nobody has to be a member of anything to send an email to the list. You don't have to subscribe, you just have to send an email. > You'll have to talk to > people on that mailing list. The horror! > You'll have to convince them your addition is > important. Then maybe it'll be added." I don't think that's unreasonable, otherwise the page would descend into total garbage very rapidly. Sites like Wikipedia and StackOverflow depend on thousands of active contributors to keep the signal to noise ratio high and we don't have the resources. > - this amounts to telling most people > to go away. I've tried to improve the info at the top of the page. If you think it can still be improved please make suggestions.
Usually diagnostics include the option that enables/disables them in [] brackets. The documentation for this option should explain things.
All this discussion was already summarised (and more) here: https://gcc.gnu.org/wiki/FAQ#diagnostics_list The bottom-line is that if you think such list would be useful, nothing is stopping you from making it happen. We cannot open the wiki to anonymous registered users due to spam, so sending suggestions via gcc-help (or bugzilla) are a way to demonstrate that you are a human interested in helping and eventually getting direct wiki access.