GNU bug report logs - #29165
26.0.90; can't use some code byte-compiled under emacs 24

Previous Next

Package: emacs;

Reported by: Ken Raeburn <raeburn <at> permabit.com>

Date: Mon, 6 Nov 2017 06:58:02 UTC

Severity: normal

Tags: fixed, patch

Found in versions 26.1, 26.0.90

Fixed in version 27.1

Done: Noam Postavsky <npostavs <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Ken Raeburn <raeburn <at> permabit.com>, 29165 <at> debbugs.gnu.org, Philipp Stephani <p.stephani2 <at> gmail.com>, Andreas Schwab <schwab <at> linux-m68k.org>
Subject: bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24
Date: Thu, 14 Dec 2017 20:16:20 -0500
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> (And if we’re going to make that sort of thing an error, we should
>>> probably check whether empty &key or &aux variable lists are similarly
>>> rejected.  I haven’t looked.)
>
> I recently installed a patch to fix/improve the behavior of &aux with no
> keyword variable (I bumped into it while working on some Elisp package,
> tho I can't remember which right now).
>
> I think it's usually worth the small extra effort to support &optional
> not followed by any var (as well as &aux not followed by any var) since
> it sometimes comes in handy.  But not if it costs extra at run-time.

I don't think there is any performance penalty (when running
byte-compiled code anyway).  Although I see that &optional at the end of
the arglist has been a compile error for a long time (I tested back to
24.3).  E.g., (defun foo (&optional)) fails to compile.  (defun foo
(&optional &rest)) happened to work, though I wouldn't exactly call that
"support".

>> Updated patch which handles &aux as well.  I also tested a bootstrap
>> (doing this I found the previous patch messed up some positive cases).
>
> To the extent that &aux is only handled by macro-expansion, accepting an
> empty &aux never costs anything at run-time, so I think rejecting it is
> a disservice to our users.

I don't see the use case for empty &aux, but I don't mind reverting that
change.




This bug report was last modified 7 years and 137 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.