GNU bug report logs - #46636
28.0.50; M-: (funcall #'or) doesn't throw an error

Previous Next

Package: emacs;

Reported by: Pip Cet <pipcet <at> gmail.com>

Date: Fri, 19 Feb 2021 13:28:01 UTC

Severity: minor

Found in version 28.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Pip Cet <pipcet <at> gmail.com>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 46636 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>
Subject: bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
Date: Fri, 19 Feb 2021 18:10:26 +0000
On Fri, Feb 19, 2021 at 4:46 PM Philipp Stephani <p.stephani2 <at> gmail.com> wrote:
> Am Fr., 19. Feb. 2021 um 15:03 Uhr schrieb Andreas Schwab
> <schwab <at> linux-m68k.org>:
> >
> > On Feb 19 2021, Pip Cet wrote:
> >
> > > Recipe starting from emacs -Q:
> > >
> > > M-: (funcall #'or) RET
> >
> > If you want authentic results, use ielm, not eval-expression.
>
> Ah, so the rewrite that macroexpand-all (in macroexp--expand-all)
> performs is the culprit here.

Yes, I think so.

> Maybe it should only rewrite if the
> first argument is indeed a function, or an autoload of a function?

I'm unconvinced it's worth it at all to rewrite funcalls or applys,
either in macroexp or in the byte compiler.

But if we have to, we have to make sure (apply #'or nil) and (funcall
#'or) are rejected somewhere (maybe as early as the #').




This bug report was last modified 3 years and 58 days ago.

Previous Next


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