Subject: bug#78394: 31.0.50; Questions about native-comp-speed and type decl

From: Eli Zaretskii <[email-masked]>
Date: Tue, 01 Jul 2025 14:18:28 +0300

> From: "Yue Yi" <[email-masked]>
> Cc: "78394" <[email-masked]>, "Eli&nbsp;Zaretskii" <[email-masked]>
> 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.