public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Nathanael Nerode <neroden@twcny.rr.com>
To: Giovanni Bajo <giovannibajo@libero.it>
Cc: gcc@gcc.gnu.org
Subject: Re: Suggestion for new keywords in bugzilla
Date: Fri, 23 May 2003 15:45:00 -0000	[thread overview]
Message-ID: <3ECE4105.4090104@twcny.rr.com> (raw)
In-Reply-To: <40d401c32114$3cf24a00$c64f2697@bagio>

Giovanni Bajo wrote:
> Nathanael Nerode wrote:
> 
> 
>>I actually thought that there should be two keywords for this:
> 
> 
>>missing-diagnostic (There should be a warning, but there isn't.)
>>misleading-diagnostic (There's a warning which shouldn't be there, or
>>should be replaced by a different warning.)
> 
> 
> The latter (misleading-diagnostic) can apply also to error messages. There
> are situations where error messages are totally wrong (for instance, they
> show unreadable names because they can't pretty-print correctly them, or
> they are totally unrelated to the real error), or could be improved (for
> instance, a simply "parse error", or "expected primary-expression" instead
> of something more detailed which would help the user understanding the
> problem).
> 
> But in the first place, why do you think that two keywords could be useful?
> I think the biggest difference is between diagnostic bugs which are request
> for enhancements and not strictly necessary, and diagnostic bugs which are
> really bugs (or at least, can be considered as such). And this difference is
> already taken into account by the Severity of the bug. In other words I
> suggest that your missing-diagnostic be simply a diagnostic keyword with
> Severity = enhancement, and you misleading-diagnostic be a diagnostic
> keyword with Severity != enhancement.
This isn't *exactly* what I was thinking of.  A missing diagnostic might 
be a warning which is supposed to trigger and doesn't.  A misleading 
diagnostic would be one which triggers but shouldn't.

It may be that the distinction is not valuable.  I defer to others.

> 
> Giovanni Bajo
> 
> 


  reply	other threads:[~2003-05-23 15:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-23 10:26 Giovanni Bajo
2003-05-23 15:45 ` Nathanael Nerode [this message]
2003-05-27 14:03   ` Giovanni Bajo
  -- strict thread matches above, loose matches on Subject: below --
2003-05-23 10:36 Volker Reichelt
2003-05-23 15:34 ` Nathanael Nerode
2003-05-22 17:56 Nathanael Nerode
2003-05-22 17:24 Nathanael Nerode
2003-05-22 18:19 ` Michael S. Zick
2003-05-22 18:21 ` Joseph S. Myers
2003-05-22 16:07 Volker Reichelt
2003-05-22 16:21 ` Daniel Berlin
2003-05-22 12:56 Volker Reichelt
2003-05-22 15:13 ` Giovanni Bajo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ECE4105.4090104@twcny.rr.com \
    --to=neroden@twcny.rr.com \
    --cc=gcc@gcc.gnu.org \
    --cc=giovannibajo@libero.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).