bug#23528: Subject: 25.0.93; Errors are ignored if I load eieio and evaluate the byte-compiled form

bug#23528: Subject: 25.0.93; Errors are ignored if I load eieio and evaluate the byte-compiled form

[Sho Takemori]

[-- Attachment #1: Type: text/plain, Size: 3202 bytes --]

If I load eieio and byte-compile a function, then some errors are ignored.

To reproduce,
1. Start emacs with emacs -Q.
2. Evaluate the following form.

(progn
  (require 'eieio)
  (defun my-this-should-raise-error ()
    (/ 1 0)
    (+ 1 2))
  (byte-compile 'my-this-should-raise-error)
  (my-this-should-raise-error))

This should raise the arith-error but it returns 3 without errors.
Can someone else reproduce this?

Best regards,
Sho Takemori

In GNU Emacs 25.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.7)
 of 2016-05-13 built on HP500-270jp
Repository revision: 66cd4d8bd031fb5cb1c65e3b008681021ea32906
Windowing system distributor 'The X.Org Foundation', version 11.0.11702000
System Description: Ubuntu 15.10

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LANG: ja_JP.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
3 (#o3, #x3, ?\C-c)

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils eieio
byte-opt bytecomp byte-compile cl-extra help-mode easymenu cconv
eieio-core cl-macs gv cl-loaddefs pcase cl-lib time-date mule-util
japan-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 98112 5616)
 (symbols 48 20752 0)
 (miscs 40 474 82)
 (strings 32 17493 4672)
 (string-bytes 1 522963)
 (vectors 16 14345)
 (vector-slots 8 533787 4648)
 (floats 8 193 12)
 (intervals 56 208 0)
 (buffers 976 11)
 (heap 1024 33967 958))

[-- Attachment #2: Type: text/html, Size: 4363 bytes --]

bug#23528: 25.0.93; Errors are ignored if I load eieio and evaluate the byte-compiled form

[Sho Takemori]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

I narrow down the problem.

If I load the following code which is taken from eieio-core.el, line 84, (I
added (require 'cl-lib))
then (progn (byte-compile 'my-this-should-raise-error)
(my-this-should-raise-error))
does not raise an error.

(progn
(require 'cl-lib)
;; 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
(:constructor nil)
(:constructor eieio--class-make (name))
(:include cl--class)
(:copier nil))
children
initarg-tuples ;; initarg tuples list
(class-slots nil :type eieio--slot)
class-allocation-values ;; class allocated value vector
default-object-cache ;; what a newly created object would look like.
; This will speed up instantiation time as
; only a `copy-sequence' will be needed, instead of
; looping over all the values and setting them from
; the default.
options ;; storage location of tagged class option
; Stored outright without modifications or stripping
)
;; Set it back to the default value.
(cl-declaim (optimize (safety 1))))

Best regards,
Sho Takemori

[-- Attachment #2: Type: text/html, Size: 1283 bytes --]

bug#23528: 25.0.93; Errors are ignored if I load eieio and evaluate the byte-compiled form

[Michael Heerdegen]

Sho Takemori <stakemorii@gmail.com> writes:

> eieio-core.el
> (progn
> (require 'cl-lib)
> ;; Arrange for field access not to bother checking if the access is indeed
> ;; made to an eieio--class object.
> (cl-declaim (optimize (safety 0)))
> [...]

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

Thanks for investigating.

Looks like loading "eieio-core" can permanently change the value of
`byte-compile-delete-errors'.

And at least, the last declaim form should be

    (cl-declaim (optimize (safety 3)))
                                  ^
to have the desired effect of setting `byte-compile-delete-errors' to
nil.

Can someone with knowledge of eieio please care about this?


Thanks,

Michael. 

bug#23528: 25.0.93; Errors are ignored if I load eieio and evaluate the byte-compiled form

[Sho Takemori]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

Thanks for the comment. I didn't know about `byte-compile-delete-errors'.
Btw, why is your comment not displayed at
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23528?
Sho Takemori

2016-05-14 0:31 GMT+09:00 Michael Heerdegen <michael_heerdegen@web.de>:

> Sho Takemori <stakemorii@gmail.com> writes:
>
> > eieio-core.el
> > (progn
> > (require 'cl-lib)
> > ;; Arrange for field access not to bother checking if the access is
> indeed
> > ;; made to an eieio--class object.
> > (cl-declaim (optimize (safety 0)))
> > [...]
>
> > ;; Set it back to the default value.
> > (cl-declaim (optimize (safety 1))))
>
> Thanks for investigating.
>
> Looks like loading "eieio-core" can permanently change the value of
> `byte-compile-delete-errors'.
>
> And at least, the last declaim form should be
>
>     (cl-declaim (optimize (safety 3)))
>                                   ^
> to have the desired effect of setting `byte-compile-delete-errors' to
> nil.
>
> Can someone with knowledge of eieio please care about this?
>
>
> Thanks,
>
> Michael.
>

[-- Attachment #2: Type: text/html, Size: 1687 bytes --]

bug#23528: 25.0.93; Errors are ignored if I load eieio and evaluate the byte-compiled form

[Michael Heerdegen]

Sho Takemori <stakemorii@gmail.com> writes:

> Thanks for the comment. I didn't know about `byte-compile-delete-errors'.
> Btw, why is your comment not displayed at
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23528?

Apparently we have some technical problem with the mailing lists or
Gmane or so.  At least did my answer now appear in the thread in quoted
form in your reply ;-)


Michael.

bug#23528: Subject: 25.0.93; Errors are ignored if I load eieio and evaluate the byte-compiled form

[Noam Postavsky]

close 23528
unarchive 27340
merge 23528 27340
quit

Sho Takemori <stakemorii@gmail.com> writes:

> If I load eieio and byte-compile a function, then some errors are
> ignored.
>
> To reproduce,
> 1. Start emacs with emacs -Q.
> 2. Evaluate the following form.
>
> (progn
>   (require 'eieio)
>   (defun my-this-should-raise-error ()
>     (/ 1 0)
>     (+ 1 2))
>   (byte-compile 'my-this-should-raise-error)
>   (my-this-should-raise-error))
>
> This should raise the arith-error but it returns 3 without errors. 
> Can someone else reproduce this?

This is fixed in version 26.