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

Previous Next

Package: emacs;

Reported by: "Yue Yi" <include_yy <at> qq.com>

Date: Mon, 12 May 2025 15:56:01 UTC

Severity: normal

Found in version 31.0.50

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

Bug is archived. No further changes may be made.

Full log


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?




This bug report was last modified 1 day ago.

Previous Next


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