GNU bug report logs - #49291
[akater] [PATCH] lisp/emacs-lisp/eieio.el (initialize-instance): Fix initform

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Wed, 30 Jun 2021 13:33:02 UTC

Severity: normal

Tags: patch

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 49291 in the body.
You can then email your comments to 49291 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#49291; Package emacs. (Wed, 30 Jun 2021 13:33:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stefan Monnier <monnier <at> iro.umontreal.ca>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 30 Jun 2021 13:33:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: bug-gnu-emacs <at> gnu.org
Cc: akater <nuclearspace <at> gmail.com>
Subject: [akater] [PATCH] lisp/emacs-lisp/eieio.el (initialize-instance):
 Fix initform
Date: Wed, 30 Jun 2021 09:32:32 -0400
[Message part 1 (text/plain, inline)]
Better make it an actual bug report, so we have a bug-number.


        Stefan

[Message part 2 (message/rfc822, inline)]
From: akater <nuclearspace <at> gmail.com>
To: emacs-devel <at> gnu.org
Subject: [PATCH] lisp/emacs-lisp/eieio.el (initialize-instance): Fix initform
Date: Wed, 30 Jun 2021 12:45:27 +0000
[Message part 3 (text/plain, inline)]

[signature.asc (application/pgp-signature, inline)]
[0001-lisp-emacs-lisp-eieio.el-initialize-instance-Fix-ini.patch (text/x-diff, attachment)]
[Message part 6 (text/plain, inline)]
* Summary
According to CLHS,
#+begin_quote
A default initial value form for a slot is defined by using the
:initform slot option to defclass. If no initialization argument
associated with that slot is given as an argument to make-instance or is
defaulted by :default-initargs, this default initial value form is
evaluated in the lexical environment of the defclass form that defined
it, and the resulting value is stored in the slot.
#+end_quote
--- [[clhs::07_a.htm][Object Creation and Initialization]]

This is not what happens in eieio.  Rather, initform is evaluated even
when initarg is present.

* Emacs Lisp examples
Define a class with a slot that has an initarg and an initform involving
undefined function:
#+begin_src emacs-lisp
(defclass test-initform ()
  ((test-slot :initarg :test-slot :initform (identity (non-existent)))))
#+end_src

Now,
#+begin_src emacs-lisp :results code :wrap example emacs-lisp
(condition-case err (make-instance 'test-initform :test-slot 0)
  (t err))
#+end_src

#+RESULTS:
#+begin_example emacs-lisp
(void-function non-existent)
#+end_example

Even though initform should not be evaluated since initarg is provided.

* Other references from CLHS
#+begin_quote
If the initialization argument has a value in the initialization
argument list, the value is stored into the slot of the newly created
object, overriding any :initform form associated with the slot.
#+end_quote
--- [[clhs::07_aa.htm][Initialization Arguments]]

#+begin_quote
An :initform form is used to initialize a slot only if no initialization
argument associated with that slot is given as an argument to
make-instance or is defaulted by :default-initargs.
#+end_quote
--- [[clhs::07_ac.htm][Defaulting of Initialization Arguments]]

#+begin_quote
If a slot has both an :initform form and an :initarg slot option, and
the initialization argument is defaulted using :default-initargs or is
supplied to make-instance, the captured :initform form is neither used
nor evaluated.
#+end_quote
--- [[clhs::07_ad.htm][Rules for Initialization Arguments]]

* Common Lisp examples
Define a class in exactly the same way as in Emacs Lisp:
#+begin_src lisp :results errors :wrap example lisp
(defclass test-initform ()
  ((test-slot :initarg :test-slot :initform (identity (non-existent)))))
#+end_src

#+RESULTS:
#+begin_example lisp
; in: DEFCLASS TEST-INITFORM
;     (NON-EXISTENT)
; 
; caught STYLE-WARNING:
;   undefined function: COMMON-LISP-USER::NON-EXISTENT
; 
; compilation unit finished
;   Undefined function:
;     NON-EXISTENT
;   caught 1 STYLE-WARNING condition
#+end_example

Appropriately,
#+begin_src lisp :results value verbatim :wrap example lisp
(ignore-errors (make-instance 'test-initform))
#+end_src

#+RESULTS:
#+begin_example lisp
NIL
#<UNDEFINED-FUNCTION NON-EXISTENT {10052CF123}>
#+end_example

But with initarg, there is no need to evaluate initform, and it is not
evaluated:
#+begin_src lisp :results value verbatim :wrap example lisp
(make-instance 'test-initform :test-slot 0)
#+end_src

#+RESULTS:
#+begin_example lisp
#<TEST-INITFORM {1005224E13}>
#+end_example

* Notes
** Initializing to quoted initform
Emacs 27 source claims:
#+begin_quote
Paul Landes said in an email:
> CL evaluates it if it can, and otherwise, leaves it as
> the quoted thing as you already have.  This is by the
> Sonya E. Keene book and other things I've look at on the
> web.
#+end_quote
--- [[file:/usr/share/emacs/27.2/lisp/emacs-lisp/eieio.el::;; Paul Landes said in an email:][EIEIO on initform quoting]]

And eieio does quote initform forms with cars being symbols that are not fbound:
#+begin_src lisp :results none
(defclass test-initform-quote ()
  ((test-slot :initform (non-existent))))
#+end_src

#+begin_src emacs-lisp :results code :wrap example emacs-lisp
(slot-value (make-instance 'test-initform-quote) 'test-slot)
#+end_src

#+RESULTS:
#+begin_example emacs-lisp
(non-existent)
#+end_example

There is however no reference to Sonya E. Keene or anything else.  Meanwhile,
#+begin_src lisp :results errors :wrap example lisp
(defclass test-initform-quote ()
  ((test-slot :initform (non-existent))))
#+end_src

#+RESULTS:
#+begin_example lisp
; in: DEFCLASS TEST-INITFORM-QUOTE
;     (NON-EXISTENT)
; 
; caught STYLE-WARNING:
;   undefined function: COMMON-LISP-USER::NON-EXISTENT
; 
; compilation unit finished
;   Undefined function:
;     NON-EXISTENT
;   caught 1 STYLE-WARNING condition
#+end_example

#+begin_src lisp :results value verbatim :wrap example emacs-lisp
(ignore-errors (make-instance 'test-initform-quote))
#+end_src

#+RESULTS:
#+begin_example emacs-lisp
NIL
#<UNDEFINED-FUNCTION NON-EXISTENT {1003251A33}>
#+end_example

Also, when discussing interplay between initform and default-initargs, Sonya E. Keene mentions:
#+begin_quote
The value of an :initform is evaluated each time it is used to initialize a slot.
#+end_quote
--- Sonya E. Keene, Object Oriented Programming in Common Lisp:
    A Programmer's Guide.  9.3. Controlling Initialization
    With ~defclass~ Options

similarly stated in CLHS, in “Macro DEFCLASS”.

Emacs 28 source removes the claim but adds
#+begin_quote
FIXME: Historically, EIEIO used a heuristic to try and guess
whether the initform is a form to be evaluated or just
a constant.  We use `eieio--eval-default-p' to see what the
heuristic says and if it disagrees with normal evaluation
then tweak the initform to make it fit and emit
a warning accordingly.
#+end_quote
--- [[file:~/src/emacs/lisp/emacs-lisp/eieio.el::;; FIXME: Historically, EIEIO used a heuristic to try and guess][eieio in git]]

which arguably makes matters even more confusing.  There should be no
such heuristic.

* Patch
We offer a patch for Emacs 28 (master) but we can't build Emacs 28 (the
bug had been filed) so it's untested and “works for me”.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49291; Package emacs. (Wed, 30 Jun 2021 15:17:01 GMT) Full text and rfc822 format available.

Message #8 received at 49291 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 49291 <at> gnu.org
Cc: akater <nuclearspace <at> gmail.com>
Subject: Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el
 (initialize-instance): Fix initform
Date: Wed, 30 Jun 2021 09:39:46 -0400
Stefan Monnier [2021-06-30 09:32:32] wrote:

> This is not what happens in eieio.  Rather, initform is evaluated even
> when initarg is present.

Good catch, thanks.

> @@ -756,13 +756,15 @@ defclass eieio-default-superclass nil
>      (dotimes (i (length slots))
>        ;; For each slot, see if we need to evaluate it.
>        (let* ((slot (aref slots i))
> +             (slot-name (eieio-slot-descriptor-name slot))
>               (initform (cl--slot-descriptor-initform slot)))
>          ;; Those slots whose initform is constant already have the right
>          ;; value set in the default-object.
> -        (unless (macroexp-const-p initform)
> +        (unless (or (rassq slot-name
> +                           (eieio--class-initarg-tuples this-class))
> +                    (macroexp-const-p initform))
>            ;; FIXME: We should be able to just do (aset this (+ i <cst>) dflt)!
> -          (eieio-oset this (cl--slot-descriptor-name slot)
> -                      (eval initform t))))))
> +          (eieio-oset this slot-name (eval initform t))))))
>    ;; Shared initialize will parse our slots for us.
>    (shared-initialize this slots))

Hmm... if I read this correctly, you prevents the (eval initform t) for
all slots that were declared with `:initarg <KEYWORD>`, whereas AFAIK the
right semantic is to prevent the (eval initform t) in the case where the
corresponding <KEYWORD> was passed to `make-instance`.

So we should pay attention to `slots` (the arg, not the local var) to
decide whether to skip (eval initform t).


        Stefan






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49291; Package emacs. (Wed, 30 Jun 2021 15:20:02 GMT) Full text and rfc822 format available.

Message #11 received at 49291 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: akater <nuclearspace <at> gmail.com>
Cc: 49291 <at> debbugs.gnu.org
Subject: Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el
 (initialize-instance): Fix initform
Date: Wed, 30 Jun 2021 11:18:52 -0400
akater [2021-06-30 14:02:01] wrote:
> You're right, I'll check for `slots`.  Got confused as to where initargs
> were stored, and lost the check.

Sorry, I mistyped the address in my reply, it should be

    49291 <AT> debbugs.gnu.org

instead of

    49291 <AT> gnu.org






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49291; Package emacs. (Wed, 30 Jun 2021 17:01:01 GMT) Full text and rfc822 format available.

Message #14 received at 49291 <at> debbugs.gnu.org (full text, mbox):

From: akater <nuclearspace <at> gmail.com>
To: 49291 <at> debbugs.gnu.org
Subject: [akater] Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el
 (initialize-instance): Fix initform
Date: Wed, 30 Jun 2021 16:49:15 +0000
[Message part 1 (text/plain, inline)]
-------------------- Start of forwarded message --------------------
From: akater <nuclearspace <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, 49291 <at> gnu.org
Subject: Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el
 (initialize-instance): Fix initform
Date: Wed, 30 Jun 2021 16:44:12 +0000

[Message part 2 (text/plain, inline)]
There are iusses, some stylistic, some related to comments in the code.

- There is a comment here:

> First, see if any of our defaults are `lambda', and
> re-evaluate them and apply the value to our slots.             

I don't observe anything like this happening.  Looks like it refers to
eieio-default-eval-maybe (likely referring to any compound form with
fbound car as to `lambda') which used to be in eieio-core in 27 but now
is gone.  Maybe we should drop this comment?

- There is a comment:

> For each slot, see if we need to evaluate it

Slots are self-evaluating objects; I think it was meant to be “to
evaluate its initform”.

- There is FIXME

> FIXME: We should be able to just do (aset this (+ i <cst>) dflt)!                                                          

Local variable dflt had been removed after Emacs 27 release.  The
comment should likely have been gone too, or at least updated.  It
suggests to assign the value of initform with a low-level `aset' applied
to eieio--class struct but (1) I don't understand the + i shift (2)
eieio--class is not declared to be of :type vector, neither does it
inherit from a struct declared to be of :type vector.  I suggest to
replace the comment with
“TODO: maybe specify eieio--class as vector and use aset here”

- I employ when-let which requires subr-x at compile time.  I can't
check the build cleanly right now, only with some dirty reverts related
to libseccomp issues but aside from that, this subr-x dependency doesn't
break byte-compilation of eieio.el.  I hope it's fine?

[signature.asc (application/pgp-signature, inline)]
[0001-lisp-emacs-lisp-eieio.el-initialize-instance-Fix-eva.patch (text/x-diff, attachment)]
[Message part 5 (text/plain, inline)]
-------------------- End of forwarded message --------------------
[Message part 6 (text/plain, inline)]

[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49291; Package emacs. (Wed, 30 Jun 2021 18:59:01 GMT) Full text and rfc822 format available.

Message #17 received at 49291 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 49291 <at> debbugs.gnu.org
Subject: [akater] Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el
 (initialize-instance): Fix initform
Date: Wed, 30 Jun 2021 14:57:52 -0400
[Message part 1 (text/plain, inline)]
[ Why, oh why, did I mistype this? ]

[Message part 2 (message/rfc822, inline)]
From: akater <nuclearspace <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, 49291 <at> gnu.org
Subject: Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el
 (initialize-instance): Fix initform
Date: Wed, 30 Jun 2021 16:44:12 +0000
[Message part 3 (text/plain, inline)]
There are iusses, some stylistic, some related to comments in the code.

- There is a comment here:

> First, see if any of our defaults are `lambda', and
> re-evaluate them and apply the value to our slots.             

I don't observe anything like this happening.  Looks like it refers to
eieio-default-eval-maybe (likely referring to any compound form with
fbound car as to `lambda') which used to be in eieio-core in 27 but now
is gone.  Maybe we should drop this comment?

- There is a comment:

> For each slot, see if we need to evaluate it

Slots are self-evaluating objects; I think it was meant to be “to
evaluate its initform”.

- There is FIXME

> FIXME: We should be able to just do (aset this (+ i <cst>) dflt)!                                                          

Local variable dflt had been removed after Emacs 27 release.  The
comment should likely have been gone too, or at least updated.  It
suggests to assign the value of initform with a low-level `aset' applied
to eieio--class struct but (1) I don't understand the + i shift (2)
eieio--class is not declared to be of :type vector, neither does it
inherit from a struct declared to be of :type vector.  I suggest to
replace the comment with
“TODO: maybe specify eieio--class as vector and use aset here”

- I employ when-let which requires subr-x at compile time.  I can't
check the build cleanly right now, only with some dirty reverts related
to libseccomp issues but aside from that, this subr-x dependency doesn't
break byte-compilation of eieio.el.  I hope it's fine?

[signature.asc (application/pgp-signature, inline)]
[0001-lisp-emacs-lisp-eieio.el-initialize-instance-Fix-eva.patch (text/x-diff, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49291; Package emacs. (Wed, 30 Jun 2021 19:14:01 GMT) Full text and rfc822 format available.

Message #20 received at 49291 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: akater <nuclearspace <at> gmail.com>
Cc: 49291 <at> debbugs.gnu.org
Subject: Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el
 (initialize-instance): Fix initform
Date: Wed, 30 Jun 2021 15:13:37 -0400
> There are iusses, some stylistic, some related to comments in the code.
> - There is a comment here:
>> First, see if any of our defaults are `lambda', and
>> re-evaluate them and apply the value to our slots.
> I don't observe anything like this happening.  Looks like it refers to
> eieio-default-eval-maybe (likely referring to any compound form with
> fbound car as to `lambda') which used to be in eieio-core in 27 but now
> is gone.

I think it's called `eieio--eval-default-p` nowadays.

> Maybe we should drop this comment?

Indeed, thanks.  `eieio--eval-default-p` is not used here any more
(it's only used in `defclass` (and its corresponding function) nowadays).

> - There is a comment:
>> For each slot, see if we need to evaluate it
> Slots are self-evaluating objects; I think it was meant to be “to
> evaluate its initform”.

LGTM, thanks.

> - There is FIXME
>> FIXME: We should be able to just do (aset this (+ i <cst>) dflt)!
> Local variable dflt had been removed after Emacs 27 release.  The
> comment should likely have been gone too, or at least updated.  It
> suggests to assign the value of initform with a low-level `aset' applied
> to eieio--class struct

No, not to the eieio--class but to the new object.
Basically replacing the `eieio-oset` with `aset`.  This is because the
vector returned by `eieio--class-slots` should contain the slots info in
the same order as the slots themselves are found in the actual object so
we don't need to ask `eieio-set` to find the slots's position in
the object.

> - I employ when-let which requires subr-x at compile time.  I can't
> check the build cleanly right now, only with some dirty reverts related
> to libseccomp issues but aside from that, this subr-x dependency doesn't
> break byte-compilation of eieio.el.  I hope it's fine?

That Looks fine, thanks.
But could you add a test or two to
test/lisp/emacs-lisp/eieio-tests/eieio-tests.el ?


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49291; Package emacs. (Thu, 01 Jul 2021 12:06:01 GMT) Full text and rfc822 format available.

Message #23 received at 49291 <at> debbugs.gnu.org (full text, mbox):

From: akater <nuclearspace <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 49291 <at> debbugs.gnu.org
Subject: Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el
 (initialize-instance): Fix initform
Date: Thu, 01 Jul 2021 11:54:32 +0000
[Message part 1 (text/plain, inline)]
> No, not to the eieio--class but to the new object.

Right, I was confused.  I left the word FIXME but rephrased the comment
so that we don't mention the non-existent dflt.  At the moment, I'm not
ready to reimplement this with aset and to ensure it would not break by
accident in an obscure manner.

> But could you add a test or two to
> test/lisp/emacs-lisp/eieio-tests/eieio-tests.el ?

I added sort of exhaustive tests for initialization.  A complete
exhaustive test would also take :default-initargs and inheritance into
account but I'd rather do this gradually.  I did not run tests in Emacs
28 but they pass as is in Emacs 27.

Some :initform's needed a fix (quote), some could be improved (search
for “symbol-value” in the patch).

The necessity to quote should be expected to break some packages, maybe
a lot.  E.g. helm contained one unquoted such instance.  I already fixed
it; nothing else broke for me so far but it was easy to omit this quote.

If authors get confused about initform workings, it may help to note
that :initform actually expects a *form*, i.e. expression to be
evaluated.  The attempt to guess what to evaluate and what not was based
on the wrong premise that CL does that.

[0001-lisp-emacs-lisp-eieio.el-initialize-instance-Fix-eva.patch (text/x-diff, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49291; Package emacs. (Thu, 01 Jul 2021 12:27:02 GMT) Full text and rfc822 format available.

Message #26 received at 49291 <at> debbugs.gnu.org (full text, mbox):

From: akater <nuclearspace <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 49291 <at> debbugs.gnu.org
Subject: Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el
 (initialize-instance): Fix initform
Date: Thu, 01 Jul 2021 12:15:47 +0000
Note: I better improve code generation in eieio-tests to cover
(hypothetical) cases where some but not all expected values are
specified, or such (hypothetical) tests will always fail.  I will
back to this, in 10 hours or so, but for existing cases, it does not
matter.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49291; Package emacs. (Fri, 02 Jul 2021 07:53:01 GMT) Full text and rfc822 format available.

Message #29 received at 49291 <at> debbugs.gnu.org (full text, mbox):

From: akater <nuclearspace <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 49291 <at> debbugs.gnu.org
Subject: Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el
 (initialize-instance): Fix initform
Date: Fri, 02 Jul 2021 07:41:26 +0000
[Message part 1 (text/plain, inline)]
A version with correct code generation.  Tests pass on 27.

“when-initargs” is not a perfect name but it's not a global macro, and
the name is short enough to allow two descriptive initargs to fit into
80 chars width so I decided not to spend time seeking for alternatives.

[0001-lisp-emacs-lisp-eieio.el-initialize-instance-Fix-eva.patch (text/x-diff, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49291; Package emacs. (Fri, 09 Jul 2021 15:01:02 GMT) Full text and rfc822 format available.

Message #32 received at 49291 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: akater <nuclearspace <at> gmail.com>
Cc: 49291 <at> debbugs.gnu.org
Subject: Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el
 (initialize-instance): Fix initform
Date: Fri, 09 Jul 2021 11:00:27 -0400
akater [2021-07-02 07:41:26] wrote:
> A version with correct code generation.  Tests pass on 27.

Sorry 'bout the delay.

> Replace :initform (symbol-value 'x) to :initform x everywhere.

This can't be right because it presumes the CLOS semantics which we
don't have yet: `:initform x` will use the symbol `x` rather than the
value of variable `x` as the default value (and it will emit a warning
because we don't want code to rely on this non-CLOS-compatible
semantics).

Hopefully we'll be able to do that in a few years, but we're not there yet.

> +(defclass eieio-tests-initargs-initform-interplay ()
> +  ((slot-with-initarg-and-initform
> +    :initarg :slot-with-initarg-and-initform
> +    :initform 'value-specified-in-defclass-form)
> +   (slot-with-initarg-only
> +    :initarg :slot-with-initarg-only)
> +   (slot-with-initform-only
> +    :initform 'value-specified-in-defclass-form)))

I don't understand how you can use this to test the interplay
between :initargs and :initform.

I thought this bug was about the fact that :iniform gets evaluated in
cases where it shouldn't, not about the final value in the object.
IOW it's about potential side-effects of evaluating :initform in cases
where we shouldn't.  But the above :initforms are all pure so I can't
see how it can test what we're after.

More to the point: the `eieio-test-25-slot-tests` extended as in your
patch passes successfully without your changes to eieio.el, so it's not
a proper regression test: we want a test that fails on the current code
and succeeds after we install your patch.

Another thing, in the patch you have:

    +(eval-when-compile (require 'cl-macs))

which is not only redundant with the (eval-when-compile (require 'cl-lib))
on the previous line, but makes assumptions about the way cl-lib is
split into files: always require `cl-lib` (rather than `cl-macs`,
`cl-extra`, etc...) when you need any part of it.


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49291; Package emacs. (Mon, 12 Jul 2021 18:44:02 GMT) Full text and rfc822 format available.

Message #35 received at 49291 <at> debbugs.gnu.org (full text, mbox):

From: akater <nuclearspace <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 49291 <at> debbugs.gnu.org
Subject: Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el
 (initialize-instance): Fix initform
Date: Mon, 12 Jul 2021 18:32:09 +0000
[Message part 1 (text/plain, inline)]
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> This can't be right because it presumes the CLOS semantics which we
> don't have yet: `:initform x` will use the symbol `x` rather than the
> value of variable `x` as the default value (and it will emit a warning
> because we don't want code to rely on this non-CLOS-compatible
> semantics).

Right.  I had to do it in Emacs 27 but it's implemented differently in
28, as should have been evident to me given the current code in
initialize-instance.

> we want a test that fails on the current code
> and succeeds after we install your patch.

OK; I replaced the tests.

[signature.asc (application/pgp-signature, inline)]
[0001-Prevent-excessive-evaluation-of-initform.patch (text/x-diff, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49291; Package emacs. (Fri, 16 Jul 2021 19:42:01 GMT) Full text and rfc822 format available.

Message #38 received at 49291 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: akater <nuclearspace <at> gmail.com>
Cc: 49291 <at> debbugs.gnu.org
Subject: Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el
 (initialize-instance): Fix initform
Date: Fri, 16 Jul 2021 15:41:16 -0400
>> we want a test that fails on the current code
>> and succeeds after we install your patch.
> OK; I replaced the tests.

Thanks, pushed to `master`.


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49291; Package emacs. (Mon, 19 Jul 2021 16:07:02 GMT) Full text and rfc822 format available.

Message #41 received at 49291 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 49291 <at> debbugs.gnu.org, akater <nuclearspace <at> gmail.com>
Subject: Re: bug#49291: [akater] [PATCH] lisp/emacs-lisp/eieio.el
 (initialize-instance): Fix initform
Date: Mon, 19 Jul 2021 18:06:04 +0200
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Thanks, pushed to `master`.

And I'm closing the bug report, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug marked as fixed in version 28.1, send any further explanations to 49291 <at> debbugs.gnu.org and Stefan Monnier <monnier <at> iro.umontreal.ca> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 19 Jul 2021 16:07:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 17 Aug 2021 11:24:09 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 224 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.