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

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.

Giovanni Bajo

             reply	other threads:[~2003-05-23 10:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-23 10:26 Giovanni Bajo [this message]
2003-05-23 15:45 ` Nathanael Nerode
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='40d401c32114$3cf24a00$c64f2697@bagio' \
    --to=giovannibajo@libero.it \
    --cc=gcc@gcc.gnu.org \
    --cc=neroden@twcny.rr.com \
    /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).