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

Previous Next

Full log

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <acorallo <at> gnu.org>
To: "Yue Yi" via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: 78394 <at> debbugs.gnu.org, Yue Yi <include_yy <at> qq.com>
Subject: Re: bug#78394: 31.0.50; Questions about native-comp-speed and type
 decl
Date: Mon, 30 Jun 2025 03:31:53 -0400

"Yue Yi" via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> Hello Emacs maintainers,
>
> 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.

Hi Yue,

yep that's correct with (declare (ftype (function (t plist) (or string
null)))) it works as expected.

> 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?

Yep the manual says 'Incorrect type declarations may cause crashes in
natively compiled code'.

> 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?

The doc for compilation-safety says:

"Possible values are:
  0 - emitted code can misbehave, even crash Emacs, if declarations of
      functions do not correctly describe their actual behavior;
  1 - emitted code is to be generated in a safe manner, even if functions
      are mis-declared."

The situation for 'compilation-safety' with the current code in case of
incorrect declarations is:

0 we perform optimizations, code can even crash.
1 it cannot crash but still we can perform some otimizations (which can
  produce unexpected results at execution time).

If we are unsatisfied with this granularity we could introduce a new value:

2 no optimizations are performed based on function type declarations.

Mmmh maybe is not a bad idea.

  Andrea

Previous Next

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