Subject: bug#78056: 31.0.50; bug in `cl-eval-when` with symbols with positions

From: David Ponce <[email-masked]>
Date: Sun, 27 Apr 2025 09:15:23 +0200

On 2025-04-27 07:13, Stefan Monnier wrote:
>>>> (cl-typep '(foo) 'cons-car-foo)
>>>> => (invalid-function #<symbol lambda at 125>)
>>>>
>>>> Without compile in the `cl-eval-when' in `cl-deftype', there is no side effect.
> 
> To fix this problem, `cl-eval-when` would need to do the same kind of
> `byte-run-strip-symbol-positions` dance as is done for
> `eval-when-compile` and `eval-and-compile`.
> 
> But I suggest the patch below instead, which starts by acknowledging
> that `cl-eval-when` doesn't actually distinguish if it's used at
> top-level (it has an ugly hack which tries to do that, but only for those
> `cl-eval-when` nested inside another `cl-eval-when`, which his
> extremely rare, and even in those cases it's right only some of the
> time).
> 
> So the patch throws away the ugly hack and just reduces `cl-eval-when`
> to one of `eval-when-compile`, `eval-and-compile`, `progn`, or nil.
> 
> It might be worthwhile to improve our macro-expansion machinery to let
> (compiler-)macros know if they're used at top-level or not, but that's
> a larger undertaking and it will be easy to retro-fit it into this macro
> if/when we do that.
> 
> Comments, objections?

I don't have enough expertise to judge the merits of this patch, but it
seems to me a very good thing to bring `cl-eval-when' back to the standard
`eval-when-compile' and `eval-and-compile' cases as much as possible, if
only to improve the consistency of the code and simplify its maintenance.

Thanks!