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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 78394 in the body.
You can then email your comments to 78394 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Yue Yi" <include_yy <at> qq.com>
To: "bug-gnu-emacs" <bug-gnu-emacs <at> gnu.org>
Subject: 31.0.50; Questions about native-comp-speed and type decl
Date: Mon, 12 May 2025 23:55:01 +0800

[Message part 1 (text/plain, inline)]

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: ---------------------------&gt;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)) ---------------------------&gt;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: ---------------------------&gt;8<----------------------------- ;; normal (t--format-checkbox nil my/plist) ;;=&gt; "" ;; byte-code (t--format-checkbox nil my/plist) ;;=&gt; "" ;; speed 1 (t--format-checkbox nil my/plist) ;;=&gt; "" ;; speed 2 (t--format-checkbox nil my/plist) ;;=&gt; " " ---------------------------&gt;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? Best regards.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Yue Yi" <include_yy <at> qq.com>, Andrea Corallo <acorallo <at> gnu.org>
Cc: 78394 <at> debbugs.gnu.org
Subject: Re: bug#78394: 31.0.50;
 Questions about native-comp-speed and type decl
Date: Mon, 12 May 2025 19:16:07 +0300

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: acorallo <at> gnu.org
Cc: 78394 <at> debbugs.gnu.org, include_yy <at> qq.com
Subject: Re: bug#78394: 31.0.50;
 Questions about native-comp-speed and type decl
Date: Sat, 31 May 2025 12:16:23 +0300

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: acorallo <at> gnu.org
Cc: 78394 <at> debbugs.gnu.org, include_yy <at> qq.com
Subject: Re: 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.
> > 
> > 
> > 
> > 
> 
> 
> 
> 

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

From: Andrea Corallo <acorallo <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78394 <at> debbugs.gnu.org, 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 02:16:09 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

> Ping! Ping!  Andrea, could you please respond?

Sorry I completely missed this bug.  Looking at it.

  Andrea

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

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

From: "Yue Yi" <include_yy <at> qq.com>
To: "Andrea Corallo" <acorallo <at> gnu.org>
Cc: Eli&nbsp;Zaretskii <eliz <at> gnu.org>,
 78394 <78394 <at> debbugs.gnu.org>
Subject: Re: bug#78394: 31.0.50;
 Questions about native-comp-speed and type decl
Date: Mon, 30 Jun 2025 19:34:02 +0800

[Message part 1 (text/plain, inline)]

Thanks, Eli and Andrea. Date: Mon, 30 Jun 2025 03:31:53 -0400, Andrea Corallo writes, > > 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). Thank you for the explanation -- I now understand that when `compilation-safety' is set to 1 (the default), it generates code in a safer manner that avoids crashes, even if function declarations are incorrect. However, it does *not* guarantee the correctness of the generated code in such cases. > 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. Mmm, I somewhat agree with this idea. I actually discovered the consequences of incorrect type declarations while running code under ERT tests, but it��s a kind of issue that's not immediately obvious as being caused by a misdeclared type. If adding this option wouldn��t be too much trouble, please consider implementing it. TIA! By the way, would introducing this option affect native-comp-speed? Since if we had a possible value of 2, optimizations wouldn��t rely on type declarations anymore. Another possible improvement might be to clarify the docstring for compilation-safety. I mean, making it more explicitly state that it ensures *safety*, but does not guarantee *correctness*.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Yue Yi" <include_yy <at> qq.com>
Cc: acorallo <at> gnu.org, 78394 <at> debbugs.gnu.org
Subject: Re: bug#78394: 31.0.50;
 Questions about native-comp-speed and type decl
Date: Tue, 01 Jul 2025 14:18:28 +0300

> From: "Yue Yi" <include_yy <at> qq.com>
> Cc: "78394" <78394 <at> debbugs.gnu.org>, "Eli&nbsp;Zaretskii" <eliz <at> gnu.org>
> Date: Mon, 30 Jun 2025 19:34:02 +0800
> 
> > "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).
> 
> Thank you for the explanation -- I now understand that when
> `compilation-safety' is set to 1 (the default), it generates code in a
> safer manner that avoids crashes, even if function declarations are
> incorrect. However, it does *not* guarantee the correctness of the
> generated code in such cases.
> 
> > 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.
> 
> Mmm, I somewhat agree with this idea. I actually discovered the
> consequences of incorrect type declarations while running code under ERT
> tests, but it��s a kind of issue that's not immediately obvious as being
> caused by a misdeclared type. If adding this option wouldn��t be too
> much trouble, please consider implementing it. TIA!

Patches to implement it are welcome, but I tend to think this
enhancement is not very important.  After all, producing incorrect
code when the programmer provides wrong information is not unexpected,
and the fix is easy.

> Another possible improvement might be to clarify the docstring for
> compilation-safety. I mean, making it more explicitly state that it
> ensures *safety*, but does not guarantee *correctness*.

"Safe" indeed doesn't mean "correct", but I added that nit to the doc
string.

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

From: "Yue Yi" <include_yy <at> qq.com>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: Andrea Corallo <acorallo <at> gnu.org>,
 78394 <78394 <at> debbugs.gnu.org>
Subject: Re: bug#78394: 31.0.50;
 Questions about native-comp-speed and type decl
Date: Wed, 2 Jul 2025 00:14:20 +0800

[Message part 1 (text/plain, inline)]

Date: Tue, 01 Jul 2025 14:18:28 +0300, Eli Zaretskii writes, > > Mmm, I somewhat agree with this idea. I actually discovered the > > consequences of incorrect type declarations while running code under ERT > > tests, but it??s a kind of issue that's not immediately obvious as being > > caused by a misdeclared type. If adding this option wouldn??t be too > > much trouble, please consider implementing it. TIA! >  > Patches to implement it are welcome, but I tend to think this > enhancement is not very important.  After all, producing incorrect > code when the programmer provides wrong information is not unexpected, > and the fix is easy. I think that makes sense. From the perspective that programmers should be responsible for the consequences of their own mistakes, this option might introduce an unnecessary "restriction". On the other hand, adding this option wouldn't be just a simple toggle -- it would also involve changes in how the code is optimized. From what I currently understand about byte-compile and native-comp, I might not be able to implement this myself (I only know that native-comp runs through several passes :p). > > Another possible improvement might be to clarify the docstring for > > compilation-safety. I mean, making it more explicitly state that it > > ensures *safety*, but does not guarantee *correctness*. >  > "Safe" indeed doesn't mean "correct", but I added that nit to the doc > string. Thanks, I see it. SGTM.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Yue Yi" <include_yy <at> qq.com>
Cc: acorallo <at> gnu.org, 78394 <at> debbugs.gnu.org
Subject: Re: bug#78394: 31.0.50;
 Questions about native-comp-speed and type decl
Date: Sat, 12 Jul 2025 10:39:21 +0300

> From: "Yue Yi" <include_yy <at> qq.com>
> Cc: "Andrea Corallo" <acorallo <at> gnu.org>, "78394" <78394 <at> debbugs.gnu.org>
> Date: Wed, 2 Jul 2025 00:14:20 +0800
> 
> Date: Tue, 01 Jul 2025 14:18:28 +0300, Eli Zaretskii writes,
> 
> > > Mmm, I somewhat agree with this idea. I actually discovered the
> > > consequences of incorrect type declarations while running code under ERT
> > > tests, but it??s a kind of issue that's not immediately obvious as being
> > > caused by a misdeclared type. If adding this option wouldn??t be too
> > > much trouble, please consider implementing it. TIA!
> > 
> > Patches to implement it are welcome, but I tend to think this
> > enhancement is not very important.  After all, producing incorrect
> > code when the programmer provides wrong information is not unexpected,
> > and the fix is easy.
> 
> I think that makes sense. From the perspective that programmers should
> be responsible for the consequences of their own mistakes, this option
> might introduce an unnecessary "restriction".
> 
> On the other hand, adding this option wouldn't be just a simple toggle
> -- it would also involve changes in how the code is optimized. From what
> I currently understand about byte-compile and native-comp, I might not
> be able to implement this myself (I only know that native-comp runs
> through several passes :p).
> 
> > > Another possible improvement might be to clarify the docstring for
> > > compilation-safety. I mean, making it more explicitly state that it
> > > ensures *safety*, but does not guarantee *correctness*.
> > 
> > "Safe" indeed doesn't mean "correct", but I added that nit to the doc
> > string.
> 
> Thanks, I see it. SGTM.

I think this bug can now be closed, right?

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

From: "Yue Yi" <include_yy <at> qq.com>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: acorallo <acorallo <at> gnu.org>,
 78394 <78394 <at> debbugs.gnu.org>
Subject: Re: bug#78394: 31.0.50;
 Questions about native-comp-speed and type decl
Date: Sat, 12 Jul 2025 16:19:55 +0800

[Message part 1 (text/plain, inline)]

It’s good enough for me, feel free to close it, TIA.

[Message part 2 (text/html, inline)]

Message #43 received at 78394-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Yue Yi" <include_yy <at> qq.com>
Cc: acorallo <at> gnu.org, 78394-done <at> debbugs.gnu.org
Subject: Re: bug#78394: 31.0.50;
 Questions about native-comp-speed and type decl
Date: Sat, 12 Jul 2025 12:16:10 +0300

> From: "Yue Yi" <include_yy <at> qq.com>
> Cc: "acorallo" <acorallo <at> gnu.org>, "78394" <78394 <at> debbugs.gnu.org>
> Date: Sat, 12 Jul 2025 16:19:55 +0800
> 
> It’s good enough for me, feel free to close it, TIA.

Thanks, closing.

Previous Next

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