[Bug c/31983] New: Add option to gcc to display specific language manual section reference for error/warning encountered.

[Bug c/31983] New: Add option to gcc to display specific language manual section reference for error/warning encountered.

[jamesodhunt at gmail dot com]

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.


-- 
           Summary: Add option to gcc to display specific language manual
                    section reference for error/warning encountered.
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jamesodhunt 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.

[pinskia at gcc dot gnu dot org]

------- 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 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.


-- 


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.

[fang at csl dot cornell dot edu]

------- 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

[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.

[manu at gcc dot gnu dot org]

------- 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.

[pinskia at gcc dot gnu dot org]

-- 

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.

[esigra at gmail dot com]

------- 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.

[pinskia at gcc dot gnu dot org]

------- 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.

[esigra at gmail dot com]

------- 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.

[manu at gcc dot gnu dot org]

------- 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.

[esigra at gmail dot com]

------- 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.

[manu at gcc dot gnu dot org]

------- 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.

[pinskia at gcc dot gnu dot org]

------- 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.

[esigra at gmail dot com]

------- 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.

[pinskia at gcc dot gnu dot org]

------- 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