GNU bug report logs -
#53227
master: Wrong error message with M-: (funcall).
Previous Next
Reported by: Alan Mackenzie <acm <at> muc.de>
Date: Thu, 13 Jan 2022 07:40:02 UTC
Severity: minor
Tags: patch
Done: Stefan Monnier <monnier <at> iro.umontreal.ca>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 53227 in the body.
You can then email your comments to 53227 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Thu, 13 Jan 2022 07:40:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Alan Mackenzie <acm <at> muc.de>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 13 Jan 2022 07:40:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello, Emacs.
In the master branch, with emacs -Q, do
M-: (funcall) RET
.. The error message one sees is
(void-function nil)
.. This is wrong. There is no function, nil or otherwise, supplied to
funcall. The error message ought to be "Too few arguments", or
something like that.
The cause of the bug lies in Ffuncall in .../src/eval.c. There, the
code uses args[0] without first checking that nargs > 0.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Thu, 13 Jan 2022 09:14:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 53227 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 13 Jan 2022 07:39:05 +0000, Alan Mackenzie <acm <at> muc.de> said:
Alan> Hello, Emacs.
Alan> In the master branch, with emacs -Q, do
Alan> M-: (funcall) RET
Alan> .. The error message one sees is
Alan> (void-function nil)
Alan> .. This is wrong. There is no function, nil or otherwise, supplied to
Alan> funcall. The error message ought to be "Too few arguments", or
Alan> something like that.
Alan> The cause of the bug lies in Ffuncall in .../src/eval.c. There, the
Alan> code uses args[0] without first checking that nargs > 0.
Itʼs not Ffuncall's responsibility to check that, itʼs 'eval' that
should be doing it. Compare with eg M-: (format), which correctly
signals 'wrong-number-of-arguments.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Thu, 13 Jan 2022 09:34:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 53227 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
> Itʼs not Ffuncall's responsibility to check that, itʼs 'eval' that
> should be doing it. Compare with eg M-: (format), which correctly
> signals 'wrong-number-of-arguments.
Or rather macroexpand-all:
(macroexpand-all '(format))
=> (format)
(macroexpand-all '(funcall))
=> (funcall nil)
Perhaps Stefan has some insights into this; added to the CCs.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Thu, 13 Jan 2022 10:57:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 53227 <at> debbugs.gnu.org (full text, mbox):
On Jan 13 2022, Lars Ingebrigtsen wrote:
> Robert Pluim <rpluim <at> gmail.com> writes:
>
>> Itʼs not Ffuncall's responsibility to check that, itʼs 'eval' that
>> should be doing it. Compare with eg M-: (format), which correctly
>> signals 'wrong-number-of-arguments.
>
> Or rather macroexpand-all:
>
> (macroexpand-all '(format))
> => (format)
>
> (macroexpand-all '(funcall))
> => (funcall nil)
Same as bug #46636.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Thu, 13 Jan 2022 14:37:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 53227 <at> debbugs.gnu.org (full text, mbox):
> Same as bug #46636.
Actually, it's a different bug, tho its origin might be the same commit.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Thu, 13 Jan 2022 15:38:02 GMT)
Full text and
rfc822 format available.
Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
On Jan 13 2022, Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>> Same as bug #46636.
>
> Actually, it's a different bug, tho its origin might be the same commit.
It's coming from the same funcall rewrite rule.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Thu, 13 Jan 2022 15:38:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Thu, 13 Jan 2022 18:25:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 53227 <at> debbugs.gnu.org (full text, mbox):
Hello, Lars.
On Thu, Jan 13, 2022 at 10:32:44 +0100, Lars Ingebrigtsen wrote:
> Robert Pluim <rpluim <at> gmail.com> writes:
> > Itʼs not Ffuncall's responsibility to check that, itʼs 'eval' that
> > should be doing it. Compare with eg M-: (format), which correctly
> > signals 'wrong-number-of-arguments.
> Or rather macroexpand-all:
> (macroexpand-all '(format))
> => (format)
> (macroexpand-all '(funcall))
> => (funcall nil)
Yes, it is the macro expansion causing the problem, thanks.
The following fixes it (or, at least, "fixes" it; I'm not clear exactly
what the pcase--dontcare clause is there for).
diff --git a/lisp/emacs-lisp/macroexp.el b/lisp/emacs-lisp/macroexp.el
index 663856a8fb..eb5af9ece6 100644
--- a/lisp/emacs-lisp/macroexp.el
+++ b/lisp/emacs-lisp/macroexp.el
@@ -441,8 +373,9 @@ macroexp--expand-all
(macroexp--all-forms args)
form)
(macroexp--expand-all newform))))
-
- (`(funcall . ,(or `(,exp . ,args) pcase--dontcare))
+ (`(funcall)
+ form)
+ (`(funcall . (,exp . ,args))
(let ((eexp (macroexp--expand-all exp))
(eargs (macroexp--all-forms args)))
;; Rewrite (funcall #'foo bar) to (foo bar), in case `foo'
> Perhaps Stefan has some insights into this; added to the CCs.
> --
> (domestic pets only, the antidote for overdose, milk.)
> bloggy blog: http://lars.ingebrigtsen.no
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Thu, 13 Jan 2022 20:38:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 53227 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab [2022-01-13 16:37:09] wrote:
> On Jan 13 2022, Stefan Monnier via "Bug reports for GNU Emacs, the Swiss
> army knife of text editors" wrote:
>>> Same as bug #46636.
>> Actually, it's a different bug, tho its origin might be the same commit.
> It's coming from the same funcall rewrite rule.
I see you agree ;-)
The patch should hopefully fix both cases, tho as you can see the two
cases are fixed separately (which is what I mean by them being two
different bugs).
Stefan
diff --git a/lisp/emacs-lisp/macroexp.el b/lisp/emacs-lisp/macroexp.el
index b44917f7d56..33ce55a3de8 100644
--- a/lisp/emacs-lisp/macroexp.el
+++ b/lisp/emacs-lisp/macroexp.el
@@ -366,14 +366,18 @@ macroexp--expand-all
form)
(macroexp--expand-all newform))))
- (`(funcall . ,(or `(,exp . ,args) pcase--dontcare))
+ (`(funcall ,exp . ,args)
(let ((eexp (macroexp--expand-all exp))
(eargs (macroexp--all-forms args)))
;; Rewrite (funcall #'foo bar) to (foo bar), in case `foo'
;; has a compiler-macro, or to unfold it.
(pcase eexp
- (`#',f (macroexp--expand-all `(,f . ,eargs)))
+ ((and `#',f
+ (guard (not (or (special-form-p f) (macrop f)))));; bug#46636
+ (macroexp--expand-all `(,f . ,eargs)))
(_ `(funcall ,eexp . ,eargs)))))
+ (`(funcall . ,_) form) ;bug#53227
+
(`(,func . ,_)
(let ((handler (function-get func 'compiler-macro))
(funargs (function-get func 'funarg-positions)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Thu, 13 Jan 2022 21:29:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 53227 <at> debbugs.gnu.org (full text, mbox):
On Jan 13 2022, Stefan Monnier wrote:
> Andreas Schwab [2022-01-13 16:37:09] wrote:
>> On Jan 13 2022, Stefan Monnier via "Bug reports for GNU Emacs, the Swiss
>> army knife of text editors" wrote:
>>>> Same as bug #46636.
>>> Actually, it's a different bug, tho its origin might be the same commit.
>> It's coming from the same funcall rewrite rule.
>
> I see you agree ;-)
>
> The patch should hopefully fix both cases, tho as you can see the two
> cases are fixed separately (which is what I mean by them being two
> different bugs).
Are they? Why do you need the second pattern?
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Thu, 13 Jan 2022 23:53:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 53227 <at> debbugs.gnu.org (full text, mbox):
> Why do you need the second pattern?
The second pattern should let `pcase` generate better code.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Fri, 14 Jan 2022 00:05:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 53227 <at> debbugs.gnu.org (full text, mbox):
On Jan 13 2022, Stefan Monnier wrote:
>> Why do you need the second pattern?
>
> The second pattern should let `pcase` generate better code.
But it is not needed for this bug.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Fri, 14 Jan 2022 00:10:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 53227 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab [2022-01-14 01:04:47] wrote:
> On Jan 13 2022, Stefan Monnier wrote:
>>> Why do you need the second pattern?
>> The second pattern should let `pcase` generate better code.
> But it is not needed for this bug.
The actual fix is in the change from
(`(funcall . ,(or `(,exp . ,args) pcase--dontcare))
to
(`(funcall ,exp . ,args)
which makes the pattern not match `(funcall . ,_) any more.
The explicit
(`(funcall . ,_) form) ;bug#53227
is then present to make sure the first change doesn't worsen the
rest of the resulting macroexpanded code.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Fri, 14 Jan 2022 00:18:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 53227 <at> debbugs.gnu.org (full text, mbox):
On Jan 13 2022, Stefan Monnier wrote:
> The explicit
>
> (`(funcall . ,_) form) ;bug#53227
>
> is then present to make sure the first change doesn't worsen the
> rest of the resulting macroexpanded code.
I don't understand. How much better than (funcall) can it get?
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Fri, 14 Jan 2022 00:21:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 53227 <at> debbugs.gnu.org (full text, mbox):
>> (`(funcall . ,_) form) ;bug#53227
>>
>> is then present to make sure the first change doesn't worsen the
>> rest of the resulting macroexpanded code.
>
> I don't understand. How much better than (funcall) can it get?
I'm not talking about the quality of the code output by
`macroexp--expand-all` but about the quality of the code *of*
`macroexp--expand-all`.
Stefan
Added tag(s) patch.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org.
(Fri, 14 Jan 2022 01:54:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Fri, 14 Jan 2022 07:37:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 53227 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> The patch should hopefully fix both cases, tho as you can see the two
> cases are fixed separately (which is what I mean by them being two
> different bugs).
I can confirm that this fixes the reported problem (and it doesn't lead
to any test suite regressions), so please do go ahead and push it.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Fri, 14 Jan 2022 09:56:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 53227 <at> debbugs.gnu.org (full text, mbox):
On Jan 13 2022, Stefan Monnier wrote:
>>> (`(funcall . ,_) form) ;bug#53227
>>>
>>> is then present to make sure the first change doesn't worsen the
>>> rest of the resulting macroexpanded code.
>>
>> I don't understand. How much better than (funcall) can it get?
>
> I'm not talking about the quality of the code output by
> `macroexp--expand-all` but about the quality of the code *of*
> `macroexp--expand-all`.
You mean this?
@@ -534,16 +534,14 @@ byte code for macroexp--expand-all:
431 stack-ref 3
432 call 2
433 return
-434:28 stack-ref 2
-435 stack-ref 5
-436 stack-ref 3
-437 call 2
-438 return
-439:29 stack-ref 1
-440 stack-ref 4
-441 stack-ref 2
-442 call 2
-443 return
-444:30 stack-ref 2
-445 car-safe
-446 return
+434:28 stack-ref 4
+435 car-safe
+436 return
+437:29 stack-ref 1
+438 stack-ref 4
+439 stack-ref 2
+440 call 2
+441 return
+442:30 stack-ref 2
+443 car-safe
+444 return
Hardly worth optimizing for a case that never occurs, IMHO.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53227; Package
emacs.
(Fri, 14 Jan 2022 17:23:01 GMT)
Full text and
rfc822 format available.
Message #58 received at 53227 <at> debbugs.gnu.org (full text, mbox):
> You mean this?
>
> @@ -534,16 +534,14 @@ byte code for macroexp--expand-all:
> 431 stack-ref 3
> 432 call 2
> 433 return
> -434:28 stack-ref 2
> -435 stack-ref 5
> -436 stack-ref 3
> -437 call 2
> -438 return
> -439:29 stack-ref 1
> -440 stack-ref 4
> -441 stack-ref 2
> -442 call 2
> -443 return
> -444:30 stack-ref 2
> -445 car-safe
> -446 return
> +434:28 stack-ref 4
> +435 car-safe
> +436 return
> +437:29 stack-ref 1
> +438 stack-ref 4
> +439 stack-ref 2
> +440 call 2
> +441 return
> +442:30 stack-ref 2
> +443 car-safe
> +444 return
Hmm... indeed a few of the other patterns, such as:
(`(,(and fun `(lambda . ,_)) . ,args)
already prevent the optimization I was aiming for :-(
Stefan
Reply sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>:
You have taken responsibility.
(Fri, 14 Jan 2022 17:28:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Alan Mackenzie <acm <at> muc.de>:
bug acknowledged by developer.
(Fri, 14 Jan 2022 17:28:02 GMT)
Full text and
rfc822 format available.
Message #63 received at 53227-done <at> debbugs.gnu.org (full text, mbox):
>> The patch should hopefully fix both cases, tho as you can see the two
>> cases are fixed separately (which is what I mean by them being two
>> different bugs).
> I can confirm that this fixes the reported problem (and it doesn't lead
> to any test suite regressions), so please do go ahead and push it.
Done, thanks,
Stefan
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 12 Feb 2022 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 72 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.