GNU bug report logs - #76573
30.1; native compilation fails for record inside function

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lin Jian <me <at> linj.tech>
Cc: acorallo <at> gnu.org, 76573 <at> debbugs.gnu.org
Subject: Re: bug#76573: 30.1; native compilation fails for record inside
 function
Date: Sat, 26 Apr 2025 11:47:52 +0300

> From: Lin Jian <me <at> linj.tech>
> Cc: acorallo <at> gnu.org,  76573 <at> debbugs.gnu.org
> Date: Sat, 26 Apr 2025 15:50:03 +0800
> 
> 
> My point is not that the code is correct and the compiler is wrong.  To
> make it crystal clear, my point is that the following situation is
> confusing and we should make it less so.  At least the author of
> el-easydraw agrees[1] with me.
> 
> 1. This compiler error only appears in Emacs >= 30.

I don't see this as a problem.  Emacs 31 introduces quite a few
warnings were questionable or wrong techniques are used in Lisp.

> 2. This compiler error does not appear if native-comp-speed < 2.

This is unfortunate, but not unheard of: the same happens with
compiling code with GCC, for example.

Andrea, can we somehow test this with all the values of
native-comp-speed?  Why does this pop up only with some values?

> 3. It's not clear from the manual and the docstring that the code is
> wrong.

The manual and the doc string cannot possibly describe all the cases
of wrong code.  The error message is quite clear about the problem, so
I don't see a problem here.

> 4. It is not clear how to fix this error.

Define the type, of course.

> > Maybe we should make the error message more clear, like
> >
> >   Type foo-r is unknown or undefined!
> 
> It would be even better to mention how to fix this error.

Quite obviously, to fix the error, the Lisp program should define the
type.

Previous Next

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