From: Katsumi Yamaoka <yamaoka@jpl.org>
Cc: emacs-pretest-bug@gnu.org, ding@gnus.org
Subject: Re: Change in bytecomp.el breaks Gnus
Date: Thu, 11 Nov 2004 16:40:53 +0900 [thread overview]
Message-ID: <b9ysm7gq1dm.fsf@jpl.org> (raw)
In-Reply-To: <b9yd5ymkq11.fsf@jpl.org>
>>>>>> In <877jouepy8.fsf@telia.com> Henrik Enberg wrote:
>> Version 2.157 of bytecomp.el causes Gnus to fail with the following
>> backtrace:
>> Debugger entered--Lisp error: (void-function t)
>> t("nnml+sent:news" (1 . 888))
>> gnus-activate-group("nnml+sent:news" scan)
>> gnus-get-unread-articles(nil)
>> gnus-setup-news(nil nil nil)
> [...]
>> gnus-1(nil nil nil)
>> gnus()
>>>>> In <b9yd5ymkq11.fsf@jpl.org> Katsumi Yamaoka wrote:
> I got the same error last night (in Japan) and noticed removing
> gnus-start.elc seems to help. I don't think it's a Gnus' fault.
> Now I'm using the version 2.156 and rebuilt Emacs.
I found that the problem is caused if a Lisp source contains the
following forms:
(eval-when-compile
(defsubst foo ()))
(defun bar () (foo))
Where `foo' is surrounded by `eval-when-compile' since there is
no necessity of using it at run-time. In that case, the
function definition for `foo' is registered into the
`byte-compile-function-environment' variable as `(foo . t)', and
the byte compiler complains as follows:
In bar:
foobar.el:4:8:Warning: attempt to inline `t' before it was defined
foobar.el:4:8:Warning: `t' called as a function
In end of data:
foobar.el:4:1:Warning: the function `t' is not known to be defined.
I used this technique in many places of some packages including
Gnus in oder to reduce useless function symbols at run-time. If
such a technique is forbidden, I will get into a plight. Could
you also support the `(eval-when-compile (defsubst ...' forms?
Thanks in advance.
next parent reply other threads:[~2004-11-11 7:40 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 [this message]
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
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=b9ysm7gq1dm.fsf@jpl.org \
--to=yamaoka@jpl.org \
--cc=ding@gnus.org \
--cc=emacs-pretest-bug@gnu.org \
/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).