bug#27340: 26.0.50; byte-compile-delete-errors value changes unexpectedly

[npostavs]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> -(progn
> +(require 'bytecomp)
> +(require 'cl-macs)
> +(let ((byte-compile-delete-errors byte-compile-delete-errors))
>    ;; Arrange for field access not to bother checking if the access is indeed
>    ;; made to an eieio--class object.
>
> This solves the problem, though I'm not sure it is the right way.
> Loading bytecomp is necessary for `byte-compile-delete-errors',
> and cl-macs is necessary not to defer performing cl-declaim,
> i.e., to perform cl-declaim while `byte-compile-delete-errors'
> is let-bound.

Another possibility is to put `cl-declaim's in (eval-when-compile ...),
this stops them having effect when loading eieieo-core.elc (the process
compiling eieio-core.el would still be affected, but since that is
usually a batch Emacs spawned by make, it doesn't really matter).

--- i/lisp/emacs-lisp/eieio-core.el
+++ w/lisp/emacs-lisp/eieio-core.el
@@ -84,7 +84,7 @@ (defvar eieio-default-superclass nil)
 (progn
   ;; Arrange for field access not to bother checking if the access is indeed
   ;; made to an eieio--class object.
-  (cl-declaim (optimize (safety 0)))
+  (eval-when-compile (cl-declaim (optimize (safety 0))))
 
 (cl-defstruct (eieio--class
                (:constructor nil)
@@ -104,7 +104,7 @@ (cl-defstruct (eieio--class
           ; Stored outright without modifications or stripping
   )
   ;; Set it back to the default value.
-  (cl-declaim (optimize (safety 1))))
+  (eval-when-compile (cl-declaim (optimize (safety 1)))))