bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#42672: 28.0.50; cl-defgeneric with :method generates incorrect Edebu


From: Philipp Stephani
Subject: bug#42672: 28.0.50; cl-defgeneric with :method generates incorrect Edebug symbols
Date: Sun, 2 Aug 2020 13:40:50 +0200

Am So., 2. Aug. 2020 um 13:15 Uhr schrieb Philipp Stephani
<p.stephani2@gmail.com>:
>
>
> Create a file /tmp/defmethod.el:
>
> $ cat /tmp/defmethod.el
> (cl-defgeneric foo (_)
>   (:method ((_ number)) 1))
>
> Visit the file in Emacs:
>
> $ emacs -Q /tmp/defmethod.el
>
> Instrument the `cl-defgeneric' form using C-u C-M-x.  The *Messages*
> buffer now contains
>
> Edebug: nil ((_ number))
> Edebug: foo
>
> The second line is for the generic function itself.  The first line,
> however, is for the method defined by the `:method' form.  But its name
> should be `foo ((_ number))', not `nil ((_ number))'.  This becomes a
> problem if there are multiple such generic functions with different
> names but identical signatures, because Edebug will then generate
> duplicate symbols.  This breaks e.g. coverage instrumentation because
> the instrumented frequencies will be attached to the wrong symbol.
>
> Implementation-wise, I guess this is a problem with
> `edebug-match-cl-generic-method-args'.  That function contains the
> snippet
>
>     ;; Append the arguments to edebug-def-name.
>     (setq edebug-def-name
>           (intern (format "%s %s" edebug-def-name args)))
>
> However, `edebug-def-name' is only non-nil when using `cl-defmethod',
> not when using `cl-defgeneric' with `:method'.
>


The code in edebug.el is somewhat obscure, but I think one piece of
the problem is that `edebug-make-form-wrapper' unconditionally binds
`edebug-def-name' to nil, so such Edebug specifications don't really
work the way they are intended to work. There's some commented-out
binding of `edebug-containing-def-name' in that function, indicating
that the function is incomplete/buggy, and the corrected
implementation was intended to cover this case (and similar cases with
nested definitions such as `cl-flet').





reply via email to

[Prev in Thread] Current Thread [Next in Thread]