GNU bug report logs - #24913
25.1.50; Emacs accepts undocumented and confusing combinations of &optional and &rest in argument lists

Previous Next

Full log

View this message in rfc822 format

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Gemini Lasswell <gazally <at> runbox.com>
Cc: 24913 <at> debbugs.gnu.org
Subject: bug#24913: 25.1.50; Emacs accepts undocumented and confusing combinations of &optional and &rest in argument lists
Date: Sun, 20 Nov 2016 12:41:02 +0000

[Message part 1 (text/plain, inline)]

Gemini Lasswell <gazally <at> runbox.com> schrieb am So., 20. Nov. 2016 um
07:31 Uhr:

> Philipp Stephani <p.stephani2 <at> gmail.com> writes:
>
> >  A more general solution would be to have the byte compiler try to match
> >  Edebug specs, and issue a warning or an error if it fails. That would
> >  help find errors in the invocations of all macros, not just ones with
> >  argument lists.
> >
> > I don't understand how this is related. This is only about function
> > definitions in the evaluator and the byte compiler. I don't see how
> > Edebug could help here.
>
> Edebug specs describe the expected syntax for the arguments of a macro,
> including the macros which define functions, such as lambda, defun,
> defmacro etc. If Edebug can't match the actual arguments in a macro
> invocation to the Edebug spec for that macro, it will signal an error.
> For an example of Edebug catching a misplaced &optional in an argument
> list, see bug#24762.
>
> So part of my suggestion is that since there exists in Emacs a powerful
> mechanism for checking macro argument lists, it would be better to use
> it if we want to let programmers know that their macro invocations are
> incorrect, instead of adding error checking to individual macros on a
> case by case basis.
>
> Another thought going into this suggestion is my observation that it's
> not difficult to find bugs in Edebug specs in the Emacs sources right
> now. One cause of that could be the Edebug spec documentation, which
> could be improved. But I think the primary reason is that a macro with a
> broken Edebug spec won't cause an error until someone tries to use
> Edebug or Testcover on an invocation of that macro, which maybe isn't
> common practice when reviewing changes. But if the byte compiler checked
> Edebug specs and signaled errors, then at least those errors in Edebug
> specs which can be found statically would be noticed immediately.
>

Integrating Edebug checks, byte-compiler checks, and evaluator checks
sounds like the right thing to do, but also like a huge amount of work that
is out of scope for this bug. Please create a new bug if you want that.
Note that a generic checker would still need to catch cases such as
(funcall (function (lambda (&rest))) ())
that don't involve any macros.

[Message part 2 (text/html, inline)]

Previous Next

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