GNU bug report logs - #78394
31.0.50; Questions about native-comp-speed and type decl

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: acorallo <at> gnu.org
Cc: 78394 <at> debbugs.gnu.org, include_yy <at> qq.com
Subject: bug#78394: 31.0.50; Questions about native-comp-speed and type decl
Date: Sat, 28 Jun 2025 11:48:11 +0300

Ping! Ping!  Andrea, could you please respond?

> Cc: 78394 <at> debbugs.gnu.org, include_yy <at> qq.com
> Date: Sat, 31 May 2025 12:16:23 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> Ping!  Andrea, could you please answer these questions?
> 
> > Cc: 78394 <at> debbugs.gnu.org
> > Date: Mon, 12 May 2025 19:16:07 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > 
> > > Date: Mon, 12 May 2025 23:55:01 +0800
> > > From:  "Yue Yi" via "Bug reports for GNU Emacs,
> > >  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> > > 
> > > When modifying an org HTML export backend, I tentatively added type
> > > annotations to a function to make the code run faster. However, during
> > > unit testing, byte compilation produced correct results, while native
> > > compilation did not. Specifically, the following cleaned-up code
> > > illustrates the issue:
> > > 
> > > --------------------------->8<-----------------------------
> > > (defconst my/plist '(:html-checkbox-type unicode))
> > > (defconst t-checkbox-types
> > >   '(( unicode .
> > >       ((on . "�7�1") (off . "�7�0")
> > >        (trans . "�7�2")))))
> > > 
> > > (let ((native-comp-speed 2))
> > >   (defun t--checkbox (checkbox info)
> > >     "Format CHECKBOX into HTML."
> > >     (declare (ftype (function (t plist) string))
> > >     (side-effect-free t) (important-return-value t))
> > >     (cdr (assq checkbox
> > >                (cdr (assq (plist-get info :html-checkbox-type)
> > >                           t-checkbox-types)))))
> > > 
> > >   (defun t--format-checkbox (checkbox info)
> > >     "Format a CHECKBOX option to string.
> > > 
> > > CHECKBOX can be `on', `off', `trans', or anything else.
> > > Returns an empty string if CHECKBOX is not one of the these three."
> > >     (declare (ftype (function (t plist) string))
> > >     (side-effect-free t) (important-return-value t))
> > >     (let ((a (t--checkbox checkbox info)))
> > >       (concat a (and a " "))))
> > >   ;; native comp
> > >   (native-compile 't--checkbox)
> > >   (native-compile 't--format-checkbox))
> > > --------------------------->8<-----------------------------
> > > 
> > > AFACK, the default value of `native-comp-speed' is 2. In this case, the
> > > behavior of the following code is inconsistent with that of the
> > > byte-compiled or non-compiled code:
> > > 
> > > --------------------------->8<-----------------------------
> > > ;; normal
> > > (t--format-checkbox nil my/plist) ;;=> ""
> > > ;; byte-code
> > > (t--format-checkbox nil my/plist) ;;=> ""
> > > ;; speed 1
> > > (t--format-checkbox nil my/plist) ;;=> ""
> > > ;; speed 2
> > > (t--format-checkbox nil my/plist) ;;=> " "
> > > --------------------------->8<-----------------------------
> > > 
> > > Of course, we can notice that the type declaration for `t--checkbox' is
> > > problematic --- its return type should be (or null string) instead of
> > > string. After correcting this mistake, the function works properly under
> > > speed=2.
> > > 
> > > In C, we generally avoid aggressive optimizations because they can lead
> > > to unpredictable behavior. What I��d like to ask is whether similar
> > > situations can occur in Emacs Lisp��s native compilation as well --- like
> > > the issue I encountered here?
> > > 
> > > Another question is about `compilation-safety'. As I understand it, when
> > > set to 1, it prevents Emacs from crashing due to faulty
> > > optimizations. Does this mean the variable only guards against the most
> > > severe cases, rather than ensuring the correctness of optimizations in
> > > general?
> > 
> > I hope Andrea (CC'ed) will be able to answer your questions.
> > 
> > 
> > 
> > 
> 
> 
> 
> 

Previous Next

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