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