Gnus development mailing list
 help / color / mirror / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: emacs-pretest-bug@gnu.org, monnier@iro.umontreal.ca, ding@gnus.org
Subject: Re: Change in bytecomp.el breaks Gnus
Date: Sun, 14 Nov 2004 11:29:28 -0600 (CST)	[thread overview]
Message-ID: <200411141729.iAEHTSQ24178@raven.dms.auburn.edu> (raw)
In-Reply-To: <yotllld5m04b.fsf@jpl.org> (message from Katsumi Yamaoka on Sun,  14 Nov 2004 15:10:44 +0900)

Katsumi Yamaoka wrote:

   Because it will grow up to be not a few numbers of warnings if
   we don't take any countermeasure.  It makes it hard to find
   important messages from such chaos.

In Emacs, the situation is already hopeless.  I redirected make
bootstrap's error messages to a file.  That file is 8155 lines long.
Not all these lines are compiler warnings but a lot of them are.

`(elisp)Coding Conventions' says to avoid compiler warnings, but many
authors ignore this.  In fact, it seems obvious that many authors not
only do not worry about silencing compiler warnings, they do not even
look at them.  Many authors seem to believe that _all_ compiler
warnings are bogus anyway and act accordingly.  In fact, I have seen
people silence compiler warnings them without even checking whether
they are bogus or not.

Most warnings are of the "function may not be defined at runtime" or
"assignment to free variable" type.  There are such an enormous amount
of them that we have, practically speaking, no choice but to assume
that they are bogus until proven non-bogus.

Most "function from cl package called at runtime" seem to involve
situations where loading the .el file loads cl, but loading the .elc
does not.  I believe that this is acceptable, in which case most of
these warnings are bogus.

Most "obsolete variable" warnings are not bogus, but fixing them does
not seem urgent.

Most of the new "designed for interactive use" warnings are probably
not bogus, but they have to be looked at individually.

Every single "assigning to a constant" warning seemed to be non-bogus.
These are actually real non-trivial bugs, because reloading the file
will erase all changes made in the Emacs session.  I will discuss
these separately.

Sincerely,

Luc.

  parent reply	other threads:[~2004-11-14 17:29 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <877jouepy8.fsf@telia.com>
     [not found] ` <b9yd5ymkq11.fsf@jpl.org>
2004-11-11  7:40   ` Katsumi Yamaoka
2004-11-11 11:18     ` Katsumi Yamaoka
2004-11-11 17:45       ` Luc Teirlinck
2004-11-11 21:55         ` Stefan
2004-11-11 22:41           ` Luc Teirlinck
2004-11-11 22:54             ` Luc Teirlinck
2004-11-12  0:22           ` Katsumi Yamaoka
2004-11-12  3:57             ` Stefan Monnier
2004-11-12  4:30               ` Katsumi Yamaoka
2004-11-13 23:03                 ` Stefan
2004-11-14  0:14                   ` Katsumi Yamaoka
2004-11-14  5:21                     ` Stefan
2004-11-14  6:10                       ` Katsumi Yamaoka
2004-11-14  6:36                         ` Stefan
2004-11-14 13:44                           ` Katsumi Yamaoka
2004-11-14 17:29                         ` Luc Teirlinck [this message]
2004-11-14 19:17                           ` Stefan Monnier
2004-11-15 14:00                             ` Richard Stallman
2004-11-15 15:36                               ` Stefan Monnier
2004-11-15 23:22                                 ` Miles Bader
2004-11-15 23:28                                   ` Stefan Monnier
2004-11-15 23:38                                     ` Miles Bader
2004-11-15 23:44                                       ` Stefan Monnier
2004-11-15 23:57                               ` Luc Teirlinck
2004-11-16  1:29                                 ` Nick Roberts
2004-11-16  1:49                                   ` Luc Teirlinck
2004-11-16  2:19                                   ` Luc Teirlinck
2004-11-16 16:49                           ` Richard Stallman

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=200411141729.iAEHTSQ24178@raven.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=ding@gnus.org \
    --cc=emacs-pretest-bug@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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 NNTP newsgroup(s).