[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27340: 26.0.50; byte-compile-delete-errors value changes unexpectedl
From: |
Katsumi Yamaoka |
Subject: |
bug#27340: 26.0.50; byte-compile-delete-errors value changes unexpectedly |
Date: |
Thu, 15 Jun 2017 17:49:49 +0900 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (i686-pc-cygwin) |
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,