bug#24913: 25.1.50; Emacs accepts undocumented and confusing combinations of &optional and &rest in argument lists

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2271 bytes --]

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

> Philipp Stephani <p.stephani2@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.

[-- Attachment #2: Type: text/html, Size: 3414 bytes --]