[Bug other/19165] (Natural) language independent error / warning classification

[Bug other/19165] (Natural) language independent error / warning classification

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clemens1509 at web dot de

--- Comment #13 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-11-15 10:39:35 UTC ---
*** Bug 55336 has been marked as a duplicate of this bug. ***

[Bug other/19165] (Natural) language independent error / warning classification

[clemens1509 at web dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

--- Comment #14 from Clemens <clemens1509 at web dot de> 2012-11-15 15:32:11 UTC ---
As describt in duplication Bug 55336 I would extend the xml for compound
messages p.e. a warning/error which points to 2 source positions like member
initialisation and member position. In fact it is only one bug, but gcc
displays more.

[Bug other/19165] (Natural) language independent error / warning classification

[fuscated at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

Teodor Petrov <fuscated at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fuscated at gmail dot com

--- Comment #15 from Teodor Petrov <fuscated at gmail dot com> 2013-01-30 12:13:52 UTC ---
I'm speaking as one of Code::Blocks' developers:
If you implement this we'll for sure use it, because we have many complaints
similar to the one Eclipse's developers have. 

(After one such complaint I've found this bug, by the way).

Some suggestions: 
Don't pack the line/column info with the file name, if possible.
So the proposed diagnostic from this:
<diagnostic class="error"
location="/home/manuel/src/test/gcc/testsuite/gcc.dg/array-2.c:10:8">
inicializaci&#65533;n de un miembro de matriz flexible en un contexto anidado
</diagnostic>

will turn in to this, which will be easier to parse:
<diagnostic class="error"
location="/home/manuel/src/test/gcc/testsuite/gcc.dg/array-2.c" line="10"
column="8">
inicializaci&#65533;n de un miembro de matriz flexible en un contexto anidado
</diagnostic>

Also, if it is possible group the notes/instances info with the error/warning
messages. This way it will allows us to show the information in a better way.

[Bug other/19165] (Natural) language independent error / warning classification

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

--- Comment #16 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-01-30 18:18:35 UTC ---
(In reply to comment #15)
> I'm speaking as one of Code::Blocks' developers:
> If you implement this we'll for sure use it, because we have many complaints
> similar to the one Eclipse's developers have. 

If you have some developer power to spare, it may be worthwhile to try to
tackle this yourself. Otherwise I am afraid this will never be implemented in
GCC. The patch in comment #10 is very rough and outdated, but the idea is
simple. Copy diagnostic.c to diagnostic-xml.c and start modifying the output
functions to emit XML.

> Don't pack the line/column info with the file name, if possible.

This will be trivial to do.

> Also, if it is possible group the notes/instances info with the error/warning
> messages. This way it will allows us to show the information in a better way.

This will be more complicated, because the diagnostics machinery does not have
a concept of multiple messages belonging to the same diagnostic. But I think
this is eventually the way to go (and I think Gabriel, the diagnostics
maintainer, thinks the same) by the way of defining an internal representation
for diagnostics output. (http://gcc.gnu.org/ml/gcc/2012-04/msg00567.html)
Dumping this internal representation in XML format would be easy then.

But designing and implementing this IR does not seem trivial, so you may want
to start with the simple stuff.

[Bug other/19165] (Natural) language independent error / warning classification

[fuscated at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

--- Comment #17 from Teodor Petrov <fuscated at gmail dot com> 2013-01-30 20:34:00 UTC ---
(In reply to comment #16)
> 
> If you have some developer power to spare, it may be worthwhile to try to
> tackle this yourself. Otherwise I am afraid this will never be implemented in
> GCC. The patch in comment #10 is very rough and outdated, but the idea is
> simple. Copy diagnostic.c to diagnostic-xml.c and start modifying the output
> functions to emit XML.
Probably, I can spare some time, but I don't have time to spare and be bothered
with all the copyright assignments and other bureaucracy related things.

[Bug other/19165] (Natural) language independent error / warning classification

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

--- Comment #18 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-03-27 00:59:43 UTC ---
(In reply to comment #17)
> (In reply to comment #16)
> > 
> > If you have some developer power to spare, it may be worthwhile to try to
> > tackle this yourself. Otherwise I am afraid this will never be implemented in
> > GCC. The patch in comment #10 is very rough and outdated, but the idea is
> > simple. Copy diagnostic.c to diagnostic-xml.c and start modifying the output
> > functions to emit XML.
> Probably, I can spare some time, but I don't have time to spare and be bothered
> with all the copyright assignments and other bureaucracy related things.

Unfortunately, and from my own experience, I completely understand your
position. Worse, the amount of bureaucracy required seems to be random. I would
suggest to give it a token try, by sending an email to both gcc@gnu.gcc.org and
assignments@gcc.org, perhaps trying to opt for a copyright disclaimer instead.
See http://gcc.gnu.org/contribute.html#legal
If you find the process too troublesome, well, nobody can said you didn't try. 
But it would be good to announce your decision to give up in both mailing
lists, as it is difficult to estimate how many people don't contribute to gcc
just because of the bureaucracy (Although I believe the number to be larger
than the number of current contributors, sadly).
>From gcc-bugs-return-418520-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 27 01:17:40 2013
Return-Path: <gcc-bugs-return-418520-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10667 invoked by alias); 27 Mar 2013 01:17:40 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10626 invoked by uid 48); 27 Mar 2013 01:17:34 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/56699] [4.8/4.9 regression] Failed for sizeof (non-static member) in lambda expression
Date: Wed, 27 Mar 2013 01:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jason at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: Status Resolution
Message-ID: <bug-56699-4-3md8rIWLHE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56699-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56699-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-03/txt/msg01961.txt.bz2
Content-length: 490


http://gcc.gnu.org/bugzilla/show_bug.cgi?idV699

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-03-27 01:17:34 UTC ---
Fixed mainline and 4.8.1.

[Bug other/19165] (Natural) language independent error / warning classification

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |christian.friedl at gmx dot at

--- Comment #27 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 96032 has been marked as a duplicate of this bug. ***

[Bug other/19165] (Natural) language independent error / warning classification

[manu at gcc dot gnu dot org]

------- Comment #12 from manu at gcc dot gnu dot org  2009-08-08 17:05 -------
(In reply to comment #11)
> XML output), but I think in practice it's only useful if driven by 
> cooperation from IDE people who will help establish what the XML should 
> look like and commit to making an IDE use the XML output in future by 
> default when using a GCC version that supports it.

Completely agreed. 

> I imagine that the XML should have some way of marking continuation 
> messages as such, should include the option (as from 
> -fdiagnostics-show-option) in some structured way, and probably should 
> give locations and inclusion context in an XML structured way as well 
> rather than as plain text - but discussion would be needed with IDE people 
> on what information GCC can give and how an IDE could use it.

Yes, it will require some custom pretty-printing functions to handle XML
entities. I think it will also need to address some weaknesses of the current
diagnostics/pretty-printing machinery: first/last diagnostic callbacks, handle
"\n" in messages correctly, being able to construct a single diagnostic entity
from various error/warning/notes (I think this is what you mean by continuation
messages).

Nothing of this would be difficult.

In addition, GCC could expose much more info from the internal representation
through XML, when printing %T, %E, %D and such.

But it is not worth if no popular IDE is making use of it.

I just realized that Clang has already HTML output. 

http://clang.llvm.org/doxygen/HTMLRewrite_8cpp-source.html

They advance really fast! So if anyone is interested on this, he/she should
also check what Clang does and which IDEs are using Clang with HTML output, to
avoid unnecessary incompatibilities.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

[Bug other/19165] (Natural) language independent error / warning classification

[joseph at codesourcery dot com]

------- Comment #11 from joseph at codesourcery dot com  2009-08-08 16:33 -------
Subject: Re:  (Natural) language independent error / warning
 classification

On Sat, 8 Aug 2009, manu at gcc dot gnu dot org wrote:

> I am not planning to work on this further. This patch shows that it can be
> done, but I don't know if there is any interest on this.

The principle makes sense (obviously the prototype patch would need 
further work for actual inclusion, e.g. escaping of < and > signs for the 
XML output), but I think in practice it's only useful if driven by 
cooperation from IDE people who will help establish what the XML should 
look like and commit to making an IDE use the XML output in future by 
default when using a GCC version that supports it.

I imagine that the XML should have some way of marking continuation 
messages as such, should include the option (as from 
-fdiagnostics-show-option) in some structured way, and probably should 
give locations and inclusion context in an XML structured way as well 
rather than as plain text - but discussion would be needed with IDE people 
on what information GCC can give and how an IDE could use it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

[Bug other/19165] (Natural) language independent error / warning classification

[manu at gcc dot gnu dot org]

------- Comment #10 from manu at gcc dot gnu dot org  2009-08-08 16:05 -------
Created an attachment (id=18329)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18329&action=view)
XML diagnostics

A prototype of XML mode for diagnostics. The output looks like:

<diagnostic class="error"
location="/home/manuel/src/test/gcc/testsuite/gcc.dg/array-2.c:10:8">
inicializaci&#65533;n de un miembro de matriz flexible en un contexto anidado
</diagnostic>

<diagnostic class="error"
location="/home/manuel/src/test/gcc/testsuite/gcc.dg/array-2.c:10:8">
(cerca de la inicializaci&#65533;n de 'g2.f.x')
</diagnostic>

<diagnostic class="warning"
location="/home/manuel/src/test/gcc/testsuite/gcc.dg/array-2.c:13:8">
exceso de elementos en el inicializador de matriz
</diagnostic>

<diagnostic class="warning"
location="/home/manuel/src/test/gcc/testsuite/gcc.dg/array-2.c:13:8">
(cerca de la inicializaci&#65533;n de 'h1.x')
</diagnostic>

I am not planning to work on this further. This patch shows that it can be
done, but I don't know if there is any interest on this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

[Bug other/19165] (Natural) language independent error / warning classification

[tromey at gcc dot gnu dot org]

------- Comment #9 from tromey at gcc dot gnu dot org  2007-01-22 16:12 -------
Some kind of machine-readable output is necessary for use by an IDE.
Eclipse can't translate the messages after they have been emitted by GCC.
So, it should run GCC in the user's locale.
However, then it would like to differentiate between warnings and errors.
There's no way to do that without knowing all the ways that GCC might
translate the words "warning" and "error" (running in a locale Eclipse
thinks it understands is not a good option because GCC may change its
choices of translation...).  It would be friendlier if
GCC provided this information.  XML, or anything machine-readable, would be
fine.
So, yes, this is a GCC bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

[Bug other/19165] (Natural) language independent error / warning classification

[manu at gcc dot gnu dot org]

------- Comment #8 from manu at gcc dot gnu dot org  2007-01-22 08:58 -------
Is this really a bug in GCC? Eclipse should run GCC with a locale it can
understand. Then, if it wants to support other languages, it has to support
them also in the parser.

Or we go for the XML output? That would be kind of interesting...


-- 

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

[Bug other/19165] (Natural) language independent error / warning classification

[ttimo at idsoftware dot com]

------- Comment #7 from ttimo at idsoftware dot com  2006-05-15 18:42 -------
an XML output mode would solve this ( and potentially a number of other similar
issues .. like having to set -fmessage-length=0 for most analyzers )


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

[Bug other/19165] (Natural) language independent error / warning classification

[tromey at gcc dot gnu dot org]

------- Comment #6 from tromey at gcc dot gnu dot org  2005-10-23 06:47 -------
There's an Eclipse PR for this, fwiw:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=108720

If you look there you can see further motivation -- in particular,
the continuation messages that gcc sometimes prints are basically
confusing to an IDE.  

Parsing the translated message seems like a very difficult approach.
Consider messages that have printf substitutions in them for instance.
Or in the case in the above PR, there is nothing distinguishing about
some of the continuation messages.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

[Bug other/19165] (Natural) language independent error / warning classification

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-15 21:20 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-07-15 21:20:47
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

[Bug other/19165] (Natural) language independent error / warning classification

[walles at mailblocks dot com]

------- Additional Comments From walles at mailblocks dot com  2005-03-29 08:04 -------
That's what they are doing currently, but it works only for English :-(.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

[Bug other/19165] (Natural) language independent error / warning classification

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 01:46 -------
What about changing the IDEs so they understand the natural language warning/error/note 
classification instead?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

[Bug other/19165] (Natural) language independent error / warning classification

[walles at mailblocks dot com]

------- Additional Comments From walles at mailblocks dot com  2004-12-27 17:51 -------
The IDE wants to present gcc's messages to people, so it's not as if the IDE
wants to understand the messages themselves (except whether they are warnings or
errors).  Now that I read what I wrote again I can see how it sounded as if the
CDT tries to do more than that, but it doesn't.  It just wants to do
errors-vs-warnings classification.

The reason it wants to be able to tell errors from warnings is that it wants to
highlight the errors more than the warnings.  Unforturnately no sane way of
doing that seems to exist currently :-(.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165

[Bug other/19165] (Natural) language independent error / warning classification

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-27 14:29 -------
I don't think we should do this because the warnings are for people not for IDEs.  Maybe the IDEs 
should use the translated message instead aka use the .pot file from gcc to do the parsing :).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
           Priority|P2                          |P3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165