GNU bug report logs -
#76573
30.1; native compilation fails for record inside function
Previous Next
Reported by: Lin Jian <me <at> linj.tech>
Date: Tue, 25 Feb 2025 23:29:02 UTC
Severity: normal
Found in version 30.1
Done: Andrea Corallo <acorallo <at> gnu.org>
To reply to this bug, email your comments to 76573 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Tue, 25 Feb 2025 23:29:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Lin Jian <me <at> linj.tech>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 25 Feb 2025 23:29:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Run the following shell command and you see the error.
> emacs -Q --batch --eval="(native-compile (defun foo-f () (record 'foo-r)))"
Error: error (foo-f "Type foo-r missing from typeof-types!")
signal(error (foo-f "Type foo-r missing from typeof-types!"))
comp--native-compile(foo-f nil nil)
native-compile(foo-f)
eval((native-compile (defun foo-f nil (record 'foo-r))) t)
command-line-1(("--eval=(native-compile (defun foo-f () (record 'foo-r)))"))
command-line()
normal-top-level()
peculiar error: "Type foo-r missing from typeof-types!"
If you set `native-comp-speed' to -1, 0 or 1, there is no error.
> emacs -Q --batch --eval="(setopt native-comp-speed 1)" --eval="(native-compile (defun foo-f () (record 'foo-r)))"
Emacs 30.0.93 and 30.1 have this bug, while Emacs 29.4 does not.
Real world elisp packages triggering this bug are emacs-aio[1] and
el-easydraw[2].
[1]: https://github.com/skeeto/emacs-aio/issues/31
[2]: https://github.com/misohena/el-easydraw/blob/f6b0f43138693b73cb65327d28bd2a4ee1b6caa7/edraw-path.el
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Sun, 09 Mar 2025 09:34:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 76573 <at> debbugs.gnu.org (full text, mbox):
Andrea, could you please look into this?
> Cc: Andrea Corallo <acorallo <at> gnu.org>
> Date: Wed, 26 Feb 2025 07:28:31 +0800
> From: Lin Jian via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
>
> Run the following shell command and you see the error.
>
> > emacs -Q --batch --eval="(native-compile (defun foo-f () (record 'foo-r)))"
> Error: error (foo-f "Type foo-r missing from typeof-types!")
> signal(error (foo-f "Type foo-r missing from typeof-types!"))
> comp--native-compile(foo-f nil nil)
> native-compile(foo-f)
> eval((native-compile (defun foo-f nil (record 'foo-r))) t)
> command-line-1(("--eval=(native-compile (defun foo-f () (record 'foo-r)))"))
> command-line()
> normal-top-level()
> peculiar error: "Type foo-r missing from typeof-types!"
>
> If you set `native-comp-speed' to -1, 0 or 1, there is no error.
> > emacs -Q --batch --eval="(setopt native-comp-speed 1)" --eval="(native-compile (defun foo-f () (record 'foo-r)))"
>
> Emacs 30.0.93 and 30.1 have this bug, while Emacs 29.4 does not.
>
> Real world elisp packages triggering this bug are emacs-aio[1] and
> el-easydraw[2].
>
> [1]: https://github.com/skeeto/emacs-aio/issues/31
> [2]: https://github.com/misohena/el-easydraw/blob/f6b0f43138693b73cb65327d28bd2a4ee1b6caa7/edraw-path.el
>
>
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Mon, 31 Mar 2025 15:07:06 GMT)
Full text and
rfc822 format available.
Message #11 received at 76573 <at> debbugs.gnu.org (full text, mbox):
Lin Jian <me <at> linj.tech> writes:
> Run the following shell command and you see the error.
>
>> emacs -Q --batch --eval="(native-compile (defun foo-f () (record 'foo-r)))"
> Error: error (foo-f "Type foo-r missing from typeof-types!")
> signal(error (foo-f "Type foo-r missing from typeof-types!"))
> comp--native-compile(foo-f nil nil)
> native-compile(foo-f)
> eval((native-compile (defun foo-f nil (record 'foo-r))) t)
> command-line-1(("--eval=(native-compile (defun foo-f () (record 'foo-r)))"))
> command-line()
> normal-top-level()
> peculiar error: "Type foo-r missing from typeof-types!"
>
> If you set `native-comp-speed' to -1, 0 or 1, there is no error.
>> emacs -Q --batch --eval="(setopt native-comp-speed 1)"
>> --eval="(native-compile (defun foo-f () (record 'foo-r)))"
>
> Emacs 30.0.93 and 30.1 have this bug, while Emacs 29.4 does not.
>
> Real world elisp packages triggering this bug are emacs-aio[1] and
> el-easydraw[2].
>
> [1]: https://github.com/skeeto/emacs-aio/issues/31
> [2]: https://github.com/misohena/el-easydraw/blob/f6b0f43138693b73cb65327d28bd2a4ee1b6caa7/edraw-path.el
Hi Lin,
the compiler is complaining because while the code is trying to create
an object of type 'foo-r', this was actually never defined.
Typically those user defined objects are defined using higher level
constructs like 'cl-defstruct' which takes care of registering the
definition into the global state (and defining the creator
'make-foo-r').
Why is this code trying to create never defined kind of objects? Isn't
the case that the code in the file being compiled is missing some
require to the definition?
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Sun, 13 Apr 2025 07:53:04 GMT)
Full text and
rfc822 format available.
Message #14 received at 76573 <at> debbugs.gnu.org (full text, mbox):
Ping! Lin Jian, can you please answer Andrea's questions, so we could
decide how to proceed with this issue?
> Cc: 76573 <at> debbugs.gnu.org
> From: Andrea Corallo <acorallo <at> gnu.org>
> Date: Mon, 31 Mar 2025 11:06:13 -0400
>
> Lin Jian <me <at> linj.tech> writes:
>
> > Run the following shell command and you see the error.
> >
> >> emacs -Q --batch --eval="(native-compile (defun foo-f () (record 'foo-r)))"
> > Error: error (foo-f "Type foo-r missing from typeof-types!")
> > signal(error (foo-f "Type foo-r missing from typeof-types!"))
> > comp--native-compile(foo-f nil nil)
> > native-compile(foo-f)
> > eval((native-compile (defun foo-f nil (record 'foo-r))) t)
> > command-line-1(("--eval=(native-compile (defun foo-f () (record 'foo-r)))"))
> > command-line()
> > normal-top-level()
> > peculiar error: "Type foo-r missing from typeof-types!"
> >
> > If you set `native-comp-speed' to -1, 0 or 1, there is no error.
> >> emacs -Q --batch --eval="(setopt native-comp-speed 1)"
> >> --eval="(native-compile (defun foo-f () (record 'foo-r)))"
> >
> > Emacs 30.0.93 and 30.1 have this bug, while Emacs 29.4 does not.
> >
> > Real world elisp packages triggering this bug are emacs-aio[1] and
> > el-easydraw[2].
> >
> > [1]: https://github.com/skeeto/emacs-aio/issues/31
> > [2]: https://github.com/misohena/el-easydraw/blob/f6b0f43138693b73cb65327d28bd2a4ee1b6caa7/edraw-path.el
>
> Hi Lin,
>
> the compiler is complaining because while the code is trying to create
> an object of type 'foo-r', this was actually never defined.
>
> Typically those user defined objects are defined using higher level
> constructs like 'cl-defstruct' which takes care of registering the
> definition into the global state (and defining the creator
> 'make-foo-r').
>
> Why is this code trying to create never defined kind of objects? Isn't
> the case that the code in the file being compiled is missing some
> require to the definition?
>
> Andrea
>
>
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Wed, 23 Apr 2025 12:11:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 76573 <at> debbugs.gnu.org (full text, mbox):
Sorry for the late reply.
Andrea Corallo <acorallo <at> gnu.org> writes:
> the compiler is complaining because while the code is trying to create
> an object of type 'foo-r', this was actually never defined.
>
> Typically those user defined objects are defined using higher level
> constructs like 'cl-defstruct' which takes care of registering the
> definition into the global state (and defining the creator
> 'make-foo-r').
>
> Why is this code trying to create never defined kind of objects? Isn't
> the case that the code in the file being compiled is missing some
> require to the definition?
I have no idea why some elisp packages use `record' directly instead of
some higher level functions like `cl-defstruct' since I am not the
author of those packages.
If using `record' directly is a user error, I would suggest:
1. mentioning it in the manual
2. and maybe also making the behavior consistent across different
`native-comp-speed' values.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Fri, 25 Apr 2025 20:48:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 76573 <at> debbugs.gnu.org (full text, mbox):
Lin Jian <me <at> linj.tech> writes:
> Sorry for the late reply.
>
> Andrea Corallo <acorallo <at> gnu.org> writes:
>
>> the compiler is complaining because while the code is trying to create
>> an object of type 'foo-r', this was actually never defined.
>>
>> Typically those user defined objects are defined using higher level
>> constructs like 'cl-defstruct' which takes care of registering the
>> definition into the global state (and defining the creator
>> 'make-foo-r').
>>
>> Why is this code trying to create never defined kind of objects? Isn't
>> the case that the code in the file being compiled is missing some
>> require to the definition?
>
> I have no idea why some elisp packages use `record' directly instead of
> some higher level functions like `cl-defstruct' since I am not the
> author of those packages.
>
> If using `record' directly is a user error, I would suggest:
> 1. mentioning it in the manual
We can always improve the manual (patches welcome), but the docstring
for 'record' already says:
"(record TYPE &rest SLOTS)
Create a new record.
TYPE is its type as returned by ‘type-of’."
How can somebody expect this machinery to work reliably for a certain
type which was never defined?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Fri, 25 Apr 2025 21:14:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 76573 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <acorallo <at> gnu.org> writes:
> > If using `record' directly is a user error, I would suggest:
> > 1. mentioning it in the manual
> We can always improve the manual (patches welcome)
It may not be a good idea for me to write such as patch since I do not
know the inner workings of this topic.
> the docstring for 'record' already says:
>
> "(record TYPE &rest SLOTS)
>
> Create a new record.
> TYPE is its type as returned by ‘type-of’."
>
> How can somebody expect this machinery to work reliably for a certain
> type which was never defined?
Since "M-x eval-expression (type-of (record 'foo-r)) RET" works and how
to define a type is not mentioned, users may not realize that they need
to define a type first or they may think `record' will define the type
for them when necessary.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Sat, 26 Apr 2025 06:55:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 76573 <at> debbugs.gnu.org (full text, mbox):
> From: Lin Jian <me <at> linj.tech>
> Cc: 76573 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> Date: Sat, 26 Apr 2025 05:13:14 +0800
>
> Andrea Corallo <acorallo <at> gnu.org> writes:
>
> > > If using `record' directly is a user error, I would suggest:
> > > 1. mentioning it in the manual
> > We can always improve the manual (patches welcome)
>
> It may not be a good idea for me to write such as patch since I do not
> know the inner workings of this topic.
>
> > the docstring for 'record' already says:
> >
> > "(record TYPE &rest SLOTS)
> >
> > Create a new record.
> > TYPE is its type as returned by ‘type-of’."
> >
> > How can somebody expect this machinery to work reliably for a certain
> > type which was never defined?
>
> Since "M-x eval-expression (type-of (record 'foo-r)) RET" works and how
> to define a type is not mentioned, users may not realize that they need
> to define a type first or they may think `record' will define the type
> for them when necessary.
Let's take a step back and revisit the original report:
> emacs -Q --batch --eval="(native-compile (defun foo-f () (record 'foo-r)))"
Error: error (foo-f "Type foo-r missing from typeof-types!")
signal(error (foo-f "Type foo-r missing from typeof-types!"))
comp--native-compile(foo-f nil nil)
native-compile(foo-f)
eval((native-compile (defun foo-f nil (record 'foo-r))) t)
command-line-1(("--eval=(native-compile (defun foo-f () (record 'foo-r)))"))
command-line()
normal-top-level()
peculiar error: "Type foo-r missing from typeof-types!"
The discussion that followed indicates that the compiler's error
message is accurate: the code attempts to use an undefined data type.
Thus, it sounds to me that Emacs is working as intended, and we should
close this non-bug.
I don't understand how you reach the conclusion that users might think
'record' creates a type, when the compiler says the type is undefined.
Maybe we should make the error message more clear, like
Type foo-r is unknown or undefined!
Will this be an okay solution?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Sat, 26 Apr 2025 07:51:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 76573 <at> debbugs.gnu.org (full text, mbox):
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.
2. This compiler error does not appear if native-comp-speed < 2.
3. It's not clear from the manual and the docstring that the code is
wrong.
4. It is not clear how to fix this error.
> 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.
[1]: https://github.com/misohena/el-easydraw/issues/36#issuecomment-2831640002
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Sat, 26 Apr 2025 08:49:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 76573 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Sat, 26 Apr 2025 09:07:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 76573 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> > 4. It is not clear how to fix this error.
> Define the type, of course.
> > 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.
Sorry, I should have been more clear. By how to fix this error, I mean
how to define the type.
Maybe it is just misohena[1] and me, but it is not clear to us how to
define the type. Could you point us to the related doc? Thanks.
[1]: https://github.com/misohena/el-easydraw/issues/36#issuecomment-2831640002
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Sat, 26 Apr 2025 10:58:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 76573 <at> debbugs.gnu.org (full text, mbox):
> From: Lin Jian <me <at> linj.tech>
> Cc: acorallo <at> gnu.org, 76573 <at> debbugs.gnu.org
> Date: Sat, 26 Apr 2025 17:06:48 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > > 4. It is not clear how to fix this error.
> > Define the type, of course.
>
> > > 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.
>
> Sorry, I should have been more clear. By how to fix this error, I mean
> how to define the type.
>
> Maybe it is just misohena[1] and me, but it is not clear to us how to
> define the type. Could you point us to the related doc? Thanks.
AFAIU, valid types are either a primitive type (so you can only create
new types by changing the C code), or you could use make-record to
make a record whose first slot specifies the type.
Andrea, am I right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Sun, 27 Apr 2025 11:26:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 76573 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
I am the author of el-easydraw, mentioned here as misohena.
I'm confused by this issue (errors during native compilation) because
I simply used the Record type as described in the Emacs Lisp manual. I
only used the `record' function, but neither the manual nor the
docstring mentions that the symbol specified as the first TYPE
argument needs to be pre-defined. The manual does mention avoiding
type name conflicts, so I added a prefix.
https://www.gnu.org/software/emacs/manual/html_node/elisp/Records.html
However, after seeing Eli's next message, I tried using `make-record'
instead of the `record' function, and the error being discussed no
longer occurred.
> Eli Zaretskii <eliz <at> gnu.org> writes:
> AFAIU, valid types are either a primitive type (so you can only create
> new types by changing the C code), or you could use make-record to
> make a record whose first slot specifies the type.
I prepared the following two test files:
;;; test-1.el --- -*- lexical-binding: t; -*-
(defun make-test-1-obj (x y)
(record 'test-1-obj x y))
;;; test-2.el --- -*- lexical-binding: t; -*-
(defun make-test-2-obj (x y)
(let ((obj (make-record 'test-2-obj 2 nil)))
(aset obj 1 x)
(aset obj 2 y)
obj))
When I evaluated (native-compile "test-1.el"), the error being
discussed occurred (error "test-1.el" "Type test-1-obj missing from
typeof-types!").
On the other hand, (native-compile "test-2.el") did not produce any
errors.
My question is: Does the difference between the `record' function and
`make-record' function go beyond just how initial values are
specified? By analogy with vector and make-vector, string and
make-string, that's what I thought, but is there a clear distinction
among Emacs developers? Does `make-record' involve type definition
while `record' does not?
I would appreciate your insights on this matter.
--
# This email has been machine translated from Japanese to English.
AKIYAMA Kouhei
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Tue, 29 Apr 2025 21:17:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 76573 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> 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?
Similarly to GCC the compiler uses the same information inferred for
performing optimizations for producing diagnostics. As a consequence
diagnostics can vary based on the optimization level. In this specific
case the pass that performs the reasoning that triggers the message
(comp--fwprop) does run only at speed >= 2.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Tue, 29 Apr 2025 21:46:07 GMT)
Full text and
rfc822 format available.
Message #47 received at 76573 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Lin Jian <me <at> linj.tech>
>> Cc: acorallo <at> gnu.org, 76573 <at> debbugs.gnu.org
>> Date: Sat, 26 Apr 2025 17:06:48 +0800
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > > 4. It is not clear how to fix this error.
>> > Define the type, of course.
>>
>> > > 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.
>>
>> Sorry, I should have been more clear. By how to fix this error, I mean
>> how to define the type.
>>
>> Maybe it is just misohena[1] and me, but it is not clear to us how to
>> define the type. Could you point us to the related doc? Thanks.
>
> AFAIU, valid types are either a primitive type (so you can only create
> new types by changing the C code), or you could use make-record to
> make a record whose first slot specifies the type.
>
> Andrea, am I right?
In my understanding 'record' and 'make-record' are the low level
primitives to create records, but in order to _declare_ a new type to
the system the users should use 'cl-defstruct' or 'defclass'.
My idea is from the reading of the manual: "The purpose of records is to
allow programmers to create objects with new types that are not built
into Emacs. They are used as the underlying representation of
cl-defstruct and defclass instances."
In case we want to allow for compiling calls to 'record' or
'make-record' with types not declared through 'cl-defstruct' or
'defclass' we should remove the compiler error and probably make it a
warning, shouldn't be a big deal.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Wed, 30 Apr 2025 08:03:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 76573 <at> debbugs.gnu.org (full text, mbox):
AKIYAMA Kouhei <misohena <at> gmail.com> writes:
> Hello,
>
> I am the author of el-easydraw, mentioned here as misohena.
>
> I'm confused by this issue (errors during native compilation) because
> I simply used the Record type as described in the Emacs Lisp manual. I
> only used the `record' function, but neither the manual nor the
> docstring mentions that the symbol specified as the first TYPE
> argument needs to be pre-defined. The manual does mention avoiding
> type name conflicts, so I added a prefix.
>
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Records.html
>
> However, after seeing Eli's next message, I tried using `make-record'
> instead of the `record' function, and the error being discussed no
> longer occurred.
Hi!
'make-record' works only because the optimizer knows only about 'record'
:)
I'm more and more convinced now that if 'record' and 'make-record' are
documented to the user the code is valid and the compiler should compile
it.
I'm testing this which demotes the error to a warning:
=========
modified lisp/emacs-lisp/comp-cstr.el
@@ -35,6 +35,7 @@
;;; Code:
+(require 'warnings)
(require 'cl-lib)
(require 'cl-extra) ;HACK: For `cl-find-class' when `cl-loaddefs' is missing.
@@ -338,7 +339,11 @@ comp--intersection
(defun comp-supertypes (type)
"Return the ordered list of supertypes of TYPE."
(or (assq type (comp-cstr-ctxt-typeof-types comp-ctxt))
- (error "Type %S missing from typeof-types!" type)))
+ (progn
+ (display-warning
+ 'native-compiler
+ (format "Type %S missing from typeof-types!" type))
+ '(t))))
(defun comp--union-typesets (&rest typesets)
"Union types present into TYPESETS."
=========
But if really this is, even if seldomly used, valid code maybe we should
not even signal a warning at this point? Dunno, Eli WDYT?
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Wed, 30 Apr 2025 08:30:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 76573 <at> debbugs.gnu.org (full text, mbox):
> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 76573 <at> debbugs.gnu.org, Lin Jian
> <me <at> linj.tech>
> Date: Wed, 30 Apr 2025 04:02:18 -0400
>
> AKIYAMA Kouhei <misohena <at> gmail.com> writes:
>
> > Hello,
> >
> > I am the author of el-easydraw, mentioned here as misohena.
> >
> > I'm confused by this issue (errors during native compilation) because
> > I simply used the Record type as described in the Emacs Lisp manual. I
> > only used the `record' function, but neither the manual nor the
> > docstring mentions that the symbol specified as the first TYPE
> > argument needs to be pre-defined. The manual does mention avoiding
> > type name conflicts, so I added a prefix.
> >
> > https://www.gnu.org/software/emacs/manual/html_node/elisp/Records.html
> >
> > However, after seeing Eli's next message, I tried using `make-record'
> > instead of the `record' function, and the error being discussed no
> > longer occurred.
>
> Hi!
>
> 'make-record' works only because the optimizer knows only about 'record'
> :)
>
> I'm more and more convinced now that if 'record' and 'make-record' are
> documented to the user the code is valid and the compiler should compile
> it.
>
> I'm testing this which demotes the error to a warning:
>
> =========
> modified lisp/emacs-lisp/comp-cstr.el
> @@ -35,6 +35,7 @@
>
> ;;; Code:
> +(require 'warnings)
> (require 'cl-lib)
> (require 'cl-extra) ;HACK: For `cl-find-class' when `cl-loaddefs' is missing.
>
> @@ -338,7 +339,11 @@ comp--intersection
> (defun comp-supertypes (type)
> "Return the ordered list of supertypes of TYPE."
> (or (assq type (comp-cstr-ctxt-typeof-types comp-ctxt))
> - (error "Type %S missing from typeof-types!" type)))
> + (progn
> + (display-warning
> + 'native-compiler
> + (format "Type %S missing from typeof-types!" type))
> + '(t))))
>
> (defun comp--union-typesets (&rest typesets)
> "Union types present into TYPESETS."
>
> =========
>
> But if really this is, even if seldomly used, valid code maybe we should
> not even signal a warning at this point? Dunno, Eli WDYT?
Possibly. Stefan, WDYT?
Also, Andrea, you suggested in a previous message that we should
document make-record as low-level facility, and suggest that new types
are created using cl-defstruct and defclass. If you still think so, I
think we should indeed make these changes in the documentation.
Stefan, any comments on this aspect?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Wed, 30 Apr 2025 09:13:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 76573 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Andrea Corallo <acorallo <at> gnu.org>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 76573 <at> debbugs.gnu.org, Lin Jian
>> <me <at> linj.tech>
>> Date: Wed, 30 Apr 2025 04:02:18 -0400
>>
>> AKIYAMA Kouhei <misohena <at> gmail.com> writes:
>>
>> > Hello,
>> >
>> > I am the author of el-easydraw, mentioned here as misohena.
>> >
>> > I'm confused by this issue (errors during native compilation) because
>> > I simply used the Record type as described in the Emacs Lisp manual. I
>> > only used the `record' function, but neither the manual nor the
>> > docstring mentions that the symbol specified as the first TYPE
>> > argument needs to be pre-defined. The manual does mention avoiding
>> > type name conflicts, so I added a prefix.
>> >
>> > https://www.gnu.org/software/emacs/manual/html_node/elisp/Records.html
>> >
>> > However, after seeing Eli's next message, I tried using `make-record'
>> > instead of the `record' function, and the error being discussed no
>> > longer occurred.
>>
>> Hi!
>>
>> 'make-record' works only because the optimizer knows only about 'record'
>> :)
>>
>> I'm more and more convinced now that if 'record' and 'make-record' are
>> documented to the user the code is valid and the compiler should compile
>> it.
>>
>> I'm testing this which demotes the error to a warning:
>>
>> =========
>> modified lisp/emacs-lisp/comp-cstr.el
>> @@ -35,6 +35,7 @@
>>
>> ;;; Code:
>> +(require 'warnings)
>> (require 'cl-lib)
>> (require 'cl-extra) ;HACK: For `cl-find-class' when `cl-loaddefs' is missing.
>>
>> @@ -338,7 +339,11 @@ comp--intersection
>> (defun comp-supertypes (type)
>> "Return the ordered list of supertypes of TYPE."
>> (or (assq type (comp-cstr-ctxt-typeof-types comp-ctxt))
>> - (error "Type %S missing from typeof-types!" type)))
>> + (progn
>> + (display-warning
>> + 'native-compiler
>> + (format "Type %S missing from typeof-types!" type))
>> + '(t))))
>>
>> (defun comp--union-typesets (&rest typesets)
>> "Union types present into TYPESETS."
>>
>> =========
>>
>> But if really this is, even if seldomly used, valid code maybe we should
>> not even signal a warning at this point? Dunno, Eli WDYT?
>
> Possibly. Stefan, WDYT?
>
> Also, Andrea, you suggested in a previous message that we should
> document make-record as low-level facility, and suggest that new types
> are created using cl-defstruct and defclass. If you still think so, I
> think we should indeed make these changes in the documentation.
Possibly, also the fact that it took quite some time to get a bug report
on this is indicative of a not common direct use of 'record' and
'make-record' by users. I'm interested as well on Stefan opinion on
this.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Sat, 10 May 2025 10:04:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 76573 <at> debbugs.gnu.org (full text, mbox):
Ping! Any further ideas for how to make progress with this issue?
> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, misohena <at> gmail.com,
> 76573 <at> debbugs.gnu.org, me <at> linj.tech
> Date: Wed, 30 Apr 2025 05:12:42 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Andrea Corallo <acorallo <at> gnu.org>
> >> Cc: Eli Zaretskii <eliz <at> gnu.org>, 76573 <at> debbugs.gnu.org, Lin Jian
> >> <me <at> linj.tech>
> >> Date: Wed, 30 Apr 2025 04:02:18 -0400
> >>
> >> AKIYAMA Kouhei <misohena <at> gmail.com> writes:
> >>
> >> > Hello,
> >> >
> >> > I am the author of el-easydraw, mentioned here as misohena.
> >> >
> >> > I'm confused by this issue (errors during native compilation) because
> >> > I simply used the Record type as described in the Emacs Lisp manual. I
> >> > only used the `record' function, but neither the manual nor the
> >> > docstring mentions that the symbol specified as the first TYPE
> >> > argument needs to be pre-defined. The manual does mention avoiding
> >> > type name conflicts, so I added a prefix.
> >> >
> >> > https://www.gnu.org/software/emacs/manual/html_node/elisp/Records.html
> >> >
> >> > However, after seeing Eli's next message, I tried using `make-record'
> >> > instead of the `record' function, and the error being discussed no
> >> > longer occurred.
> >>
> >> Hi!
> >>
> >> 'make-record' works only because the optimizer knows only about 'record'
> >> :)
> >>
> >> I'm more and more convinced now that if 'record' and 'make-record' are
> >> documented to the user the code is valid and the compiler should compile
> >> it.
> >>
> >> I'm testing this which demotes the error to a warning:
> >>
> >> =========
> >> modified lisp/emacs-lisp/comp-cstr.el
> >> @@ -35,6 +35,7 @@
> >>
> >> ;;; Code:
> >> +(require 'warnings)
> >> (require 'cl-lib)
> >> (require 'cl-extra) ;HACK: For `cl-find-class' when `cl-loaddefs' is missing.
> >>
> >> @@ -338,7 +339,11 @@ comp--intersection
> >> (defun comp-supertypes (type)
> >> "Return the ordered list of supertypes of TYPE."
> >> (or (assq type (comp-cstr-ctxt-typeof-types comp-ctxt))
> >> - (error "Type %S missing from typeof-types!" type)))
> >> + (progn
> >> + (display-warning
> >> + 'native-compiler
> >> + (format "Type %S missing from typeof-types!" type))
> >> + '(t))))
> >>
> >> (defun comp--union-typesets (&rest typesets)
> >> "Union types present into TYPESETS."
> >>
> >> =========
> >>
> >> But if really this is, even if seldomly used, valid code maybe we should
> >> not even signal a warning at this point? Dunno, Eli WDYT?
> >
> > Possibly. Stefan, WDYT?
> >
> > Also, Andrea, you suggested in a previous message that we should
> > document make-record as low-level facility, and suggest that new types
> > are created using cl-defstruct and defclass. If you still think so, I
> > think we should indeed make these changes in the documentation.
>
> Possibly, also the fact that it took quite some time to get a bug report
> on this is indicative of a not common direct use of 'record' and
> 'make-record' by users. I'm interested as well on Stefan opinion on
> this.
>
> Andrea
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Mon, 12 May 2025 07:46:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 76573 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Ping! Any further ideas for how to make progress with this issue?
Compiler-wise I'm okay to demote the error to a warning (with the
proposed patch).
Language-wise I asking myself, why should the user create records
manually if we have facilities like cl-defstruct? If there's no real
use case I think would be good to mark in the manual 'record' and
'make-record' as language machinery facilities not to be used by the
user.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Mon, 12 May 2025 14:20:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 76573 <at> debbugs.gnu.org (full text, mbox):
>> Ping! Any further ideas for how to make progress with this issue?
> Compiler-wise I'm okay to demote the error to a warning (with the
> proposed patch).
FWIW, I think `comp.el` should definitely not signal an error here.
This part of the compiler's code is trying to optimize the code, and
optimizations should never signal errors: if the code was accepted by
the byte-compiler, then it's valid and the native compiler should accept
it as well.
If you want to emit a warning, that's fine but the wording should
clarify that this is an issue of lack of info potentially relevant for
an optimization (like when we warn about defsubst defined after they've
already been called). In the current instance, I wonder if the impact
of this lack of info (on the quality of the generated code) is
sufficiently important to warrant a warning.
> Language-wise I asking myself, why should the user create records
> manually if we have facilities like cl-defstruct?
Why not? Maybe they're using their own alternative to
`cl-defstruct/defclass`?
BTW, even using `defclass` your code will still signal the same error:
% src/emacs -Q batch --eval '(progn (defclass my-foo () ((a :initarg :a))) (native-compile (defun my-fun () (record `my-foo 3))))'
Error: error (my-fun "Type my-foo missing from typeof-types!")
signal(error (my-fun "Type my-foo missing from typeof-types!"))
comp--native-compile(my-fun nil nil)
native-compile(my-fun)
(progn (defclass my-foo nil ((a :initarg :a))) (native-compile (defun my-fun nil (record `my-foo 3))))
eval((progn (defclass my-foo nil ((a :initarg :a))) (native-compile (defun my-fun nil (record `my-foo 3)))) t)
command-line-1(("--eval" "(progn (defclass my-foo () ((a :initarg :a))) (native-compile (defun my-fun () (record `my-foo 3))))"))
command-line()
normal-top-level()
debug-early-backtrace...done
peculiar error: "Type my-foo missing from typeof-types!"
%
- Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Sat, 31 May 2025 09:16:05 GMT)
Full text and
rfc822 format available.
Message #68 received at 76573 <at> debbugs.gnu.org (full text, mbox):
Ping! Andrea, any comments or suggestions, given what Stefan writes?
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, me <at> linj.tech, 76573 <at> debbugs.gnu.org,
> misohena <at> gmail.com
> Date: Mon, 12 May 2025 10:19:17 -0400
>
> >> Ping! Any further ideas for how to make progress with this issue?
> > Compiler-wise I'm okay to demote the error to a warning (with the
> > proposed patch).
>
> FWIW, I think `comp.el` should definitely not signal an error here.
> This part of the compiler's code is trying to optimize the code, and
> optimizations should never signal errors: if the code was accepted by
> the byte-compiler, then it's valid and the native compiler should accept
> it as well.
>
> If you want to emit a warning, that's fine but the wording should
> clarify that this is an issue of lack of info potentially relevant for
> an optimization (like when we warn about defsubst defined after they've
> already been called). In the current instance, I wonder if the impact
> of this lack of info (on the quality of the generated code) is
> sufficiently important to warrant a warning.
>
> > Language-wise I asking myself, why should the user create records
> > manually if we have facilities like cl-defstruct?
>
> Why not? Maybe they're using their own alternative to
> `cl-defstruct/defclass`?
>
> BTW, even using `defclass` your code will still signal the same error:
>
> % src/emacs -Q batch --eval '(progn (defclass my-foo () ((a :initarg :a))) (native-compile (defun my-fun () (record `my-foo 3))))'
>
> Error: error (my-fun "Type my-foo missing from typeof-types!")
> signal(error (my-fun "Type my-foo missing from typeof-types!"))
> comp--native-compile(my-fun nil nil)
> native-compile(my-fun)
> (progn (defclass my-foo nil ((a :initarg :a))) (native-compile (defun my-fun nil (record `my-foo 3))))
> eval((progn (defclass my-foo nil ((a :initarg :a))) (native-compile (defun my-fun nil (record `my-foo 3)))) t)
> command-line-1(("--eval" "(progn (defclass my-foo () ((a :initarg :a))) (native-compile (defun my-fun () (record `my-foo 3))))"))
> command-line()
> normal-top-level()
>
> debug-early-backtrace...done
> peculiar error: "Type my-foo missing from typeof-types!"
> %
>
>
> - Stefan
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Tue, 17 Jun 2025 07:30:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 76573 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Ping! Any further ideas for how to make progress with this issue?
Here I'm.
I've installed on master f38e969e472 which makes the native compiler
don't error when encoutering forms like (record 'undeclared-type).
I think we should port it on 30 if we see it does not regress things on
master.
Lin could you verify it works for your case?
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Tue, 17 Jun 2025 08:54:03 GMT)
Full text and
rfc822 format available.
Message #74 received at 76573 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <acorallo <at> gnu.org> writes:
> Lin could you verify it works for your case?
I cherry-picked commit f38e969 into Emacs 30.1. I can verify that
el-easydraw and emacs-aio compiles without error.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76573; Package
emacs.
(Sat, 05 Jul 2025 07:22:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 76573 <at> debbugs.gnu.org (full text, mbox):
> From: Lin Jian <me <at> linj.tech>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca,
> misohena <at> gmail.com, 76573 <at> debbugs.gnu.org
> Date: Tue, 17 Jun 2025 16:53:18 +0800
>
> Andrea Corallo <acorallo <at> gnu.org> writes:
>
> > Lin could you verify it works for your case?
>
> I cherry-picked commit f38e969 into Emacs 30.1. I can verify that
> el-easydraw and emacs-aio compiles without error.
Thanks.
Andrea, what's next? Should we backport to emacs-30?
Reply sent
to
Andrea Corallo <acorallo <at> gnu.org>:
You have taken responsibility.
(Wed, 09 Jul 2025 08:34:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Lin Jian <me <at> linj.tech>:
bug acknowledged by developer.
(Wed, 09 Jul 2025 08:34:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 76573-done <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Lin Jian <me <at> linj.tech>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca,
>> misohena <at> gmail.com, 76573 <at> debbugs.gnu.org
>> Date: Tue, 17 Jun 2025 16:53:18 +0800
>>
>> Andrea Corallo <acorallo <at> gnu.org> writes:
>>
>> > Lin could you verify it works for your case?
>>
>> I cherry-picked commit f38e969 into Emacs 30.1. I can verify that
>> el-easydraw and emacs-aio compiles without error.
>
> Thanks.
>
> Andrea, what's next? Should we backport to emacs-30?
Hi Eli,
I applied the patch to emacs-30. Tests are clean here so I pushed the
backport as 05ecb2b8f02.
Closing this then.
Regards
Andrea
This bug report was last modified 22 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.