bug#54079: 29.0.50; Method dispatching eratically fails

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Wed, Mar 09, 2022 at 13:06:11 -0500, Stefan Monnier wrote:
> >> I don't understand the scenario you're thinking of.
> >> Are you thinking of something like `(eval-when-compile (byte-compile ...))?
> > Yes.
> >> Does that ever happen in real life?
> > Probably exceedingly seldomly.
> > What's to be gained by not catering to this unusual case?  What do we
> > lose?

> We lose making it work right for the 99% other cases that *do* occur?

How would it not work right for such a case?  Can you give an example?

> >> >> And why bother stripping the result of `byte-compile-eval`?
> >> > Because it might be the result of evaluating a defun (or defvar or
> >> > defconst).

> >> AFAIK sympos should only appear within the compiler pipeline between the
> >> "read" and the "emit resulting bytecode".  They may be passed to various
> >> functions and macros along the way, but I can't think of any scenario
> >> where they'd end up returned by `(byte-compile-)eval`.

> >> > This was the situation which gave rise to the bug.

> >> Could you give some details about how it played out?
> >> [ Either here or as a comment in the code.  ]

> > Michael byte compiled cl-generic.el.  This created cl-generic.elc
> > correctly, but also left uncompiled forms in the function cells of the
> > symbols defun'd inside an eval-{when,and}-compile.  These forms
> > contained symbols with positions.

> Hmm... we're talking about stripping the result of `byte-compile-eval`.
> This function is only used for `eval-when-compile`, not `eval-and-compile`.
> And nothing in your above description indicates that the sympos appeared
> in the resulting value of `eval-when-compile` (as opposed to appearing
> in the slot of functions and variables that were set during the course
> of the evaluation).

OK, sorry, I was mistaken.  These forms with SWPs arose from
evan-AND-compile, which doesn't use byte-compile-eval.

> >> >> Fundamentally, `eval` should always strip before doing its job.
> >> > Except when what it's evaluating is a defun, defmacrro, defsubst, etc.
> >> Why?
> > Because that evaluated form might later be byte compiled, and the SWPs
> > will be needed for that.

> I don't understand the scenario you're thinking of.
> Are thinking of a case like:

> - something causes the execution of (eval '(defun foo ...))
> - the user types `M-x byte-compile RET foo RET`

Sorry again, I've lost the thread here.  Weren't we talking about
eval-{when,and}-compile, not eval?  Inside these two special forms, we
should preserve the SWPs as long as possible (i.e. as long as they won't
cause any errors).

> If so, then:
> - I don't think we should care about this case because it's extremely
>   rare and fundamentally broken (the symbol's function cell contains
>   a function *value* (i.e. a closure) and not a function's source code,
>   so in general we need `byte-compile--reify-function` which implements
>   a heuristic to go back to something like a source form, which can
>   break in various ways in corner cases).


Really?  After evaluating a defun, etc., we have a lisp form in the
function cell, which may be a closure.  The function byte-compile
compiles an arbitrary form, doesn't it?

> - If we don't strip before calling the `M-x byte-compile` then the code
>   may/will bisbehave because of the presence of the sympos.

How?  byte-compile is designed to use SWPs.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).