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

From: "Yue Yi" <[email-masked]>
Date: Wed, 2 Jul 2025 00:14:20 +0800

Date: Tue, 01 Jul 2025 14:18:28 +0300, Eli Zaretskii writes, &gt; &gt; Mmm, I somewhat agree with this idea. I actually discovered the &gt; &gt; consequences of incorrect type declarations while running code under ERT &gt; &gt; tests, but it??s a kind of issue that's not immediately obvious as being &gt; &gt; caused by a misdeclared type. If adding this option wouldn??t be too &gt; &gt; much trouble, please consider implementing it. TIA! &gt;  &gt; Patches to implement it are welcome, but I tend to think this &gt; enhancement is not very important.  After all, producing incorrect &gt; code when the programmer provides wrong information is not unexpected, &gt; 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). &gt; &gt; Another possible improvement might be to clarify the docstring for &gt; &gt; compilation-safety. I mean, making it more explicitly state that it &gt; &gt; ensures *safety*, but does not guarantee *correctness*. &gt;  &gt; "Safe" indeed doesn't mean "correct", but I added that nit to the doc &gt; string. Thanks, I see it. SGTM.