GNU bug report logs -
#78056
31.0.50; bug in `cl-eval-when` with symbols with positions
Previous Next
Full log
View this message in rfc822 format
On 2025-04-27 09:15, David Ponce wrote:
> 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!
I forgot to confirm that the patch fixed the issue :-)
Thanks!
This bug report was last modified 49 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.