numbered warnings & errors?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

numbered warnings & errors?

Zhanyong Wan (λx.x x)
Hi,

Sorry if this has been discussed before.  What do people say to
assigning each warning/error a number and printing that number as part
of the compiler message, like what MSVC does?

When we see a compiler error/warning, often we need to read up on what
it really means.  A unique number is much easier to search for than
the actual message, which can change from one version of Clang to
another.  Also different warnings/errors may have similar messages,
making a search even harder.

Unique error/warning numbers also make it easier to suppress warnings
using -W or #pragma.  When I see a warning message, I can suppress it
using the warning number in it.  I don't have to look up the symbolic
ID of the warning from the Clang documentation.  (While this problem
can be solved by printing the symbolic ID as part of the message, it's
visually more intrusive.)

Thoughts?  Thanks,

--
Zhanyong
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: numbered warnings & errors?

Chandler Carruth
On Wed, Dec 23, 2009 at 9:43 PM, Zhanyong Wan (λx.x x) <[hidden email]> wrote:

> Hi,
>
> Sorry if this has been discussed before.  What do people say to
> assigning each warning/error a number and printing that number as part
> of the compiler message, like what MSVC does?
>
> When we see a compiler error/warning, often we need to read up on what
> it really means.  A unique number is much easier to search for than
> the actual message, which can change from one version of Clang to
> another.  Also different warnings/errors may have similar messages,
> making a search even harder.
>
> Unique error/warning numbers also make it easier to suppress warnings
> using -W or #pragma.  When I see a warning message, I can suppress it
> using the warning number in it.  I don't have to look up the symbolic
> ID of the warning from the Clang documentation.  (While this problem
> can be solved by printing the symbolic ID as part of the message, it's
> visually more intrusive.)

Personally, I'd accept the intrusion to have something easier than a
number to refer to. It should be equally searchable. But I do agree
with printing some identifier, whatever form it takes.

>
> Thoughts?  Thanks,
>
> --
> Zhanyong
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: numbered warnings & errors?

Daniel Dunbar
2009/12/23 Chandler Carruth <[hidden email]>:

> On Wed, Dec 23, 2009 at 9:43 PM, Zhanyong Wan (λx.x x) <[hidden email]> wrote:
>> Hi,
>>
>> Sorry if this has been discussed before.  What do people say to
>> assigning each warning/error a number and printing that number as part
>> of the compiler message, like what MSVC does?
>>
>> When we see a compiler error/warning, often we need to read up on what
>> it really means.  A unique number is much easier to search for than
>> the actual message, which can change from one version of Clang to
>> another.  Also different warnings/errors may have similar messages,
>> making a search even harder.
>>
>> Unique error/warning numbers also make it easier to suppress warnings
>> using -W or #pragma.  When I see a warning message, I can suppress it
>> using the warning number in it.  I don't have to look up the symbolic
>> ID of the warning from the Clang documentation.  (While this problem
>> can be solved by printing the symbolic ID as part of the message, it's
>> visually more intrusive.)
>
> Personally, I'd accept the intrusion to have something easier than a
> number to refer to. It should be equally searchable. But I do agree
> with printing some identifier, whatever form it takes.

I also found the MSVC warning numbers to be really useful in practice,
but want something better. A proposal I thought about making, but
haven't actually written, was to organize diagnostics into a compact
reverse dotted notation. The idea being that a fully dotted warning
should be easy to google / search docs for, and the components in the
dot could be useful for organization and high level grouping.

I'm not in a particular rush to see this problem solved though,
because a lot of the value of having stable warning numbers/names is
in the stability, so letting our diagnostics bake for a while is good.

I'm also curious about alternate approaches which don't rely on
exposing a stable name to the user (for example, by having the
compiler embed some of the documentation, which could then have a
verbose link to more information -- it would still be keyed by some
number + version, but not in a way that needs to be stable).

 - Daniel

>>
>> Thoughts?  Thanks,
>>
>> --
>> Zhanyong
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: numbered warnings & errors?

Renato Golin
2009/12/24 Daniel Dunbar <[hidden email]>:
> I'm also curious about alternate approaches which don't rely on
> exposing a stable name to the user (for example, by having the
> compiler embed some of the documentation, which could then have a
> verbose link to more information -- it would still be keyed by some
> number + version, but not in a way that needs to be stable).

Hi Daniel.

I've used codes to determine error traces as well, when one condition
caused the other. So, for instance, if you have a tokenizer error
causing a parser error, or a lexical or syntax error, you can trace
what's really going on. A header with the error codes could make it
easier to google for it, too.

ERROR: Sema21-Tok12 (semantic analysis failed because tokenizer got EOF)

The problem with context help is that, especially in compilers, there
could be multiple causes to a specific problem and each could have
multiple fixes. Printing them out on the console would clutter a lot,
not to mention formatting that text...

Maybe, if the console supports hypertext (more likely on IDEs), you
could embed links and put the documentation online. When it's not
supported, you could print small hashes that would be redirected to
the right page when the user puts in their browsers
(firefox+google-feeling-lucky would do the trick).

cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: numbered warnings & errors?

Douglas Gregor
In reply to this post by Daniel Dunbar

On Dec 24, 2009, at 12:09 AM, Daniel Dunbar wrote:

> 2009/12/23 Chandler Carruth <[hidden email]>:
>> On Wed, Dec 23, 2009 at 9:43 PM, Zhanyong Wan (λx.x x) <[hidden email]> wrote:
>>> Hi,
>>>
>>> Sorry if this has been discussed before.  What do people say to
>>> assigning each warning/error a number and printing that number as part
>>> of the compiler message, like what MSVC does?
>>>
>>> When we see a compiler error/warning, often we need to read up on what
>>> it really means.  A unique number is much easier to search for than
>>> the actual message, which can change from one version of Clang to
>>> another.  Also different warnings/errors may have similar messages,
>>> making a search even harder.
>>>
>>> Unique error/warning numbers also make it easier to suppress warnings
>>> using -W or #pragma.  When I see a warning message, I can suppress it
>>> using the warning number in it.  I don't have to look up the symbolic
>>> ID of the warning from the Clang documentation.  (While this problem
>>> can be solved by printing the symbolic ID as part of the message, it's
>>> visually more intrusive.)
>>
>> Personally, I'd accept the intrusion to have something easier than a
>> number to refer to. It should be equally searchable. But I do agree
>> with printing some identifier, whatever form it takes.
>
> I also found the MSVC warning numbers to be really useful in practice,
> but want something better. A proposal I thought about making, but
> haven't actually written, was to organize diagnostics into a compact
> reverse dotted notation. The idea being that a fully dotted warning
> should be easy to google / search docs for, and the components in the
> dot could be useful for organization and high level grouping.

I like that idea.

> I'm not in a particular rush to see this problem solved though,
> because a lot of the value of having stable warning numbers/names is
> in the stability, so letting our diagnostics bake for a while is good.

Agreed. What I *don't* want is for us to feel restricted by an existing numbering system, where we don't want to improve diagnostics (e.g., by splitting one diagnostic into several) because some users may have suppressed that diagnostic with a pragma.

> I'm also curious about alternate approaches which don't rely on
> exposing a stable name to the user (for example, by having the
> compiler embed some of the documentation, which could then have a
> verbose link to more information -- it would still be keyed by some
> number + version, but not in a way that needs to be stable).


I take it as gospel that the documentation should be embedded in the compiler, and then any external representation of that documentation can be generated by the compiler itself. A reverse dotted notation will help us organize that documentation, and force us into the right mental model for keeping diagnostics within a particular are of the compiler consistent.

  - Doug


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: numbered warnings & errors?

Chris Lattner
On Jan 5, 2010, at 7:47 AM, Douglas Gregor wrote:
>> I'm not in a particular rush to see this problem solved though,
>> because a lot of the value of having stable warning numbers/names is
>> in the stability, so letting our diagnostics bake for a while is  
>> good.
>
> Agreed. What I *don't* want is for us to feel restricted by an  
> existing numbering system, where we don't want to improve  
> diagnostics (e.g., by splitting one diagnostic into several) because  
> some users may have suppressed that diagnostic with a pragma.

How is this different and better than the existing warning group  
stuff?  They are already hierarchical and unique.  The only difference  
is that they aren't in reverse dotted form?

>> I'm also curious about alternate approaches which don't rely on
>> exposing a stable name to the user (for example, by having the
>> compiler embed some of the documentation, which could then have a
>> verbose link to more information -- it would still be keyed by some
>> number + version, but not in a way that needs to be stable).
>
>
> I take it as gospel that the documentation should be embedded in the  
> compiler, and then any external representation of that documentation  
> can be generated by the compiler itself.

I completely agree.

-Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: numbered warnings & errors?

Douglas Gregor

On Jan 5, 2010, at 10:14 AM, Chris Lattner wrote:

> On Jan 5, 2010, at 7:47 AM, Douglas Gregor wrote:
>>> I'm not in a particular rush to see this problem solved though,
>>> because a lot of the value of having stable warning numbers/names is
>>> in the stability, so letting our diagnostics bake for a while is good.
>>
>> Agreed. What I *don't* want is for us to feel restricted by an existing numbering system, where we don't want to improve diagnostics (e.g., by splitting one diagnostic into several) because some users may have suppressed that diagnostic with a pragma.
>
> How is this different and better than the existing warning group stuff?  They are already hierarchical and unique.  The only difference is that they aren't in reverse dotted form?


I think it's the same idea, extended to all diagnostics.

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: numbered warnings & errors?

Daniel Dunbar
In reply to this post by Chris Lattner
On Tue, Jan 5, 2010 at 10:14 AM, Chris Lattner <[hidden email]> wrote:

> On Jan 5, 2010, at 7:47 AM, Douglas Gregor wrote:
>>>
>>> I'm not in a particular rush to see this problem solved though,
>>> because a lot of the value of having stable warning numbers/names is
>>> in the stability, so letting our diagnostics bake for a while is good.
>>
>> Agreed. What I *don't* want is for us to feel restricted by an existing
>> numbering system, where we don't want to improve diagnostics (e.g., by
>> splitting one diagnostic into several) because some users may have
>> suppressed that diagnostic with a pragma.
>
> How is this different and better than the existing warning group stuff?
>  They are already hierarchical and unique.  The only difference is that they
> aren't in reverse dotted form?

The notable difference is that each warning does not have a unique
hierarchical identifier which also functions as its canonical name
(i.e., in documentation). We have an ad-hoc naming convention for
diagnostics in the code, but those names aren't exposed.

>From the perspective of warning groups, most diagnostics have no name,
some have multiple names, and the names as visible to the user are
totally unrelated to the internal diagnostic names.

 - Daniel

>>> I'm also curious about alternate approaches which don't rely on
>>> exposing a stable name to the user (for example, by having the
>>> compiler embed some of the documentation, which could then have a
>>> verbose link to more information -- it would still be keyed by some
>>> number + version, but not in a way that needs to be stable).
>>
>>
>> I take it as gospel that the documentation should be embedded in the
>> compiler, and then any external representation of that documentation can be
>> generated by the compiler itself.
>
> I completely agree.
>
> -Chris
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: numbered warnings & errors?

Chris Lattner

On Jan 5, 2010, at 10:51 AM, Daniel Dunbar wrote:

>>
>> How is this different and better than the existing warning group  
>> stuff?
>>  They are already hierarchical and unique.  The only difference is  
>> that they
>> aren't in reverse dotted form?
>
> The notable difference is that each warning does not have a unique
> hierarchical identifier which also functions as its canonical name
> (i.e., in documentation). We have an ad-hoc naming convention for
> diagnostics in the code, but those names aren't exposed.
>
> From the perspective of warning groups, most diagnostics have no name,
> some have multiple names, and the names as visible to the user are
> totally unrelated to the internal diagnostic names.

Ah, so you really want a 1-1 mapping between diagnostics and "names".  
Ok.  How stable are the names though?  Would they be exposed through a  
command line interface (something like -W flags)?

-Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: numbered warnings & errors?

Daniel Dunbar
On Tue, Jan 5, 2010 at 10:52 AM, Chris Lattner <[hidden email]> wrote:

>
> On Jan 5, 2010, at 10:51 AM, Daniel Dunbar wrote:
>
>>>
>>> How is this different and better than the existing warning group stuff?
>>>  They are already hierarchical and unique.  The only difference is that
>>> they
>>> aren't in reverse dotted form?
>>
>> The notable difference is that each warning does not have a unique
>> hierarchical identifier which also functions as its canonical name
>> (i.e., in documentation). We have an ad-hoc naming convention for
>> diagnostics in the code, but those names aren't exposed.
>>
>> From the perspective of warning groups, most diagnostics have no name,
>> some have multiple names, and the names as visible to the user are
>> totally unrelated to the internal diagnostic names.
>
> Ah, so you really want a 1-1 mapping between diagnostics and "names".  Ok.

Yes, at least to satisfy the stated goal of having a single "key"
which can be used to search for information on a diagnostic or
reference documentation.

>  How stable are the names though?  Would they be exposed through a command
> line interface (something like -W flags)?

Good questions; this was more of an idea-in-my-head than a concrete
proposal I had ready to bring forward. One question I have is how much
of an interesting hierarchy can be imposed on diagnostics anyway. If I
was going to work on this, my first step would probably just to be to
organize the existing warnings identifiers into a reasonable grouping
and impose naming conventions on the identifiers. If that organization
can be well defined and documented, then perhaps it can be stabilized
into a visible warning ID.

 - Daniel

> -Chris
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev