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

[Katsumi Yamaoka <yamaoka@jpl.org>]

On Mon, 12 Jun 2017 07:12:24 -0400, npostavs@users.sourceforge.net wrote:
> It's because of the 'cl-declaim' around that 'cl-defstruct':

> (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)))

> (cl-defstruct (eieio--class
>   ...
>   )
>   ;; Set it back to the default value.
>   (cl-declaim (optimize (safety 1))))

> The problem is that the default (safety 1) value is not default with
> respect to byte-compile-delete-errors:

I see both (cl-declaim..) forms set `byte-compile-delete-errors'
to t.  Thanks.  Then I tried this:

--8<---------------cut here---------------start------------->8---
--- eieio-core.el~	2017-04-19 22:03:44.676418700 +0000
+++ eieio-core.el	2017-06-15 08:46:36.995604500 +0000
@@ -82,5 +82,7 @@
 (defvar eieio-default-superclass nil)
 
-(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.
--8<---------------cut here---------------end--------------->8---

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.

Regards,