GNU bug report logs -
#78394
31.0.50; Questions about native-comp-speed and type decl
Previous Next
Full log
Message #11 received at 78394 <at> debbugs.gnu.org (full text, mbox):
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 . "☑") (off . "☐")
> > (trans . "☒")))))
> >
> > (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.
>
>
>
>
This bug report was last modified 18 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.