GNU bug report logs -
#65030
30.0.50; Check keyword args of make-process
Previous Next
To reply to this bug, email your comments to 65030 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Thu, 03 Aug 2023 06:49:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Helmut Eller <eller.helmut <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 03 Aug 2023 06:49:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The functions make-process and make-network-process have many keyword
arguments and it's somewhat easy to misspell some of them. E.g. using
:coding-system instead of :coding. These functions don't detect such
mistakes at runtime. What would people think about adding some checks
as a compiler macro as with the patch below?
I didn't know where to put this, so I just left it in bytecomp.el.
Perhaps the advertised-calling-convention declaration could do this, but
since keyword arguments seem to be generally discouraged, a special case
for make-process and make-network-process maybe simpler.
Helmut
[0001-Check-keyword-args-of-make-process.patch (text/x-diff, inline)]
From 758ba9b8b26333fc60ca4693616c5f2b355d4fcc Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut <at> gmail.com>
Date: Thu, 3 Aug 2023 08:33:40 +0200
Subject: [PATCH] Check keyword args of make-process
The functions make-process and make-network-process have many
keyword args and it's easy to misspell some of them.
Use a compiler macro to warn about some possible mistakes.
* lisp/emacs-lisp/bytecomp.el (bytecomp--check-keyword-args): New
helper.
(make-process, make-network-process): Define a compiler macro that
performs some checks but doesn't anything else.
* test/lisp/emacs-lisp/bytecomp-tests.el: Add some tests.
* test/lisp/emacs-lisp/bytecomp-resources/:
(warn-make-process-missing-keyword-arg.el,
warn-make-process-missing-keyword-value.el,
warn-make-process-repeated-keyword-arg.el,
warn-make-process-unknown-keyword-arg.el): New test files
---
lisp/emacs-lisp/bytecomp.el | 61 +++++++++++++++++++
.../warn-make-process-missing-keyword-arg.el | 3 +
...warn-make-process-missing-keyword-value.el | 3 +
.../warn-make-process-repeated-keyword-arg.el | 3 +
.../warn-make-process-unknown-keyword-arg.el | 4 ++
test/lisp/emacs-lisp/bytecomp-tests.el | 16 +++++
6 files changed, 90 insertions(+)
create mode 100644 test/lisp/emacs-lisp/bytecomp-resources/warn-make-process-missing-keyword-arg.el
create mode 100644 test/lisp/emacs-lisp/bytecomp-resources/warn-make-process-missing-keyword-value.el
create mode 100644 test/lisp/emacs-lisp/bytecomp-resources/warn-make-process-repeated-keyword-arg.el
create mode 100644 test/lisp/emacs-lisp/bytecomp-resources/warn-make-process-unknown-keyword-arg.el
diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index 5b1d958e6c2..d3a434b5593 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -5782,6 +5782,67 @@ bytecomp--backward-word
form ; arity error
`(forward-word (- (or ,arg 1)))))
+(defun bytecomp--check-keyword-args (form arglist allowed-keys required-keys)
+ (let ((fun (car form)))
+ (cl-flet ((missing (form keyword)
+ (byte-compile-warn-x
+ form
+ "`%S´ called without required keyword argument %S"
+ fun keyword))
+ (unrecognized (form keyword)
+ (byte-compile-warn-x
+ form
+ "`%S´ called with unknown keyword argument %S"
+ fun keyword))
+ (duplicate (form keyword)
+ (byte-compile-warn-x
+ form
+ "`%S´ called with repeated keyword argument %S"
+ fun keyword))
+ (missing-val (form keyword)
+ (byte-compile-warn-x
+ form
+ "missing value for keyword argument %S"
+ keyword)))
+ (let* ((seen '())
+ (l arglist))
+ (while (consp l)
+ (let ((key (car l)))
+ (cond ((and (keywordp key) (memq key allowed-keys))
+ (cond ((memq key seen)
+ (duplicate l key))
+ (t
+ (push key seen))))
+ (t (unrecognized l key)))
+ (when (null (cdr l))
+ (missing-val l key)))
+ (setq l (cddr l)))
+ (dolist (key required-keys)
+ (unless (memq key seen)
+ (missing form key))))))
+ form)
+
+(put 'make-process 'compiler-macro
+ #'(lambda (form &rest args)
+ (bytecomp--check-keyword-args
+ form args
+ '(:name
+ :buffer :command :coding :noquery :stop :connection-type
+ :filter :sentinel :stderr :file-handler)
+ '(:name :command))))
+
+(put 'make-network-process 'compiler-macro
+ #'(lambda (form &rest args)
+ (bytecomp--check-keyword-args
+ form args
+ '(:name
+ :buffer :host :service :type :family :local :remote :coding
+ :nowait :noquery :stop :filter :filter-multibyte :sentinel
+ :log :plist :tls-parameters :server :broadcast :dontroute
+ :keepalive :linger :oobinline :priority :reuseaddr :bindtodevice
+ :use-external-socket)
+ '(:name :service))))
+
(provide 'byte-compile)
(provide 'bytecomp)
diff --git a/test/lisp/emacs-lisp/bytecomp-resources/warn-make-process-missing-keyword-arg.el b/test/lisp/emacs-lisp/bytecomp-resources/warn-make-process-missing-keyword-arg.el
new file mode 100644
index 00000000000..9369e78ff54
--- /dev/null
+++ b/test/lisp/emacs-lisp/bytecomp-resources/warn-make-process-missing-keyword-arg.el
@@ -0,0 +1,3 @@
+;;; -*- lexical-binding: t -*-
+(defun foo ()
+ (make-process :name "ls"))
diff --git a/test/lisp/emacs-lisp/bytecomp-resources/warn-make-process-missing-keyword-value.el b/test/lisp/emacs-lisp/bytecomp-resources/warn-make-process-missing-keyword-value.el
new file mode 100644
index 00000000000..4226349afef
--- /dev/null
+++ b/test/lisp/emacs-lisp/bytecomp-resources/warn-make-process-missing-keyword-value.el
@@ -0,0 +1,3 @@
+;;; -*- lexical-binding: t -*-
+(defun foo ()
+ (make-process :name "ls" :command))
diff --git a/test/lisp/emacs-lisp/bytecomp-resources/warn-make-process-repeated-keyword-arg.el b/test/lisp/emacs-lisp/bytecomp-resources/warn-make-process-repeated-keyword-arg.el
new file mode 100644
index 00000000000..18250f14ee9
--- /dev/null
+++ b/test/lisp/emacs-lisp/bytecomp-resources/warn-make-process-repeated-keyword-arg.el
@@ -0,0 +1,3 @@
+;;; -*- lexical-binding: t -*-
+(defun foo ()
+ (make-process :name "ls" :command "ls" :name "ls"))
diff --git a/test/lisp/emacs-lisp/bytecomp-resources/warn-make-process-unknown-keyword-arg.el b/test/lisp/emacs-lisp/bytecomp-resources/warn-make-process-unknown-keyword-arg.el
new file mode 100644
index 00000000000..4721035780b
--- /dev/null
+++ b/test/lisp/emacs-lisp/bytecomp-resources/warn-make-process-unknown-keyword-arg.el
@@ -0,0 +1,4 @@
+;;; -*- lexical-binding: t -*-
+(defun foo ()
+ (make-process :name "ls" :command "ls"
+ :coding-system 'binary))
diff --git a/test/lisp/emacs-lisp/bytecomp-tests.el b/test/lisp/emacs-lisp/bytecomp-tests.el
index 593fd117685..6ed907ead7b 100644
--- a/test/lisp/emacs-lisp/bytecomp-tests.el
+++ b/test/lisp/emacs-lisp/bytecomp-tests.el
@@ -1199,6 +1199,22 @@ bytecomp--tests-obsolete-var
"nowarn-inline-after-defvar.el"
"Lexical argument shadows" 'reverse)
+(bytecomp--define-warning-file-test
+ "warn-make-process-missing-keyword-arg.el"
+ "called without required keyword argument :command")
+
+(bytecomp--define-warning-file-test
+ "warn-make-process-unknown-keyword-arg.el"
+ "called with unknown keyword argument :coding-system")
+
+(bytecomp--define-warning-file-test
+ "warn-make-process-repeated-keyword-arg.el"
+ "called with repeated keyword argument :name")
+
+(bytecomp--define-warning-file-test
+ "warn-make-process-missing-keyword-value.el"
+ "missing value for keyword argument :command")
+
;;;; Macro expansion.
--
2.39.2
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Sat, 05 Aug 2023 09:22:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 65030 <at> debbugs.gnu.org (full text, mbox):
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Date: Thu, 03 Aug 2023 08:47:44 +0200
>
> The functions make-process and make-network-process have many keyword
> arguments and it's somewhat easy to misspell some of them. E.g. using
> :coding-system instead of :coding. These functions don't detect such
> mistakes at runtime. What would people think about adding some checks
> as a compiler macro as with the patch below?
>
> I didn't know where to put this, so I just left it in bytecomp.el.
>
> Perhaps the advertised-calling-convention declaration could do this, but
> since keyword arguments seem to be generally discouraged, a special case
> for make-process and make-network-process maybe simpler.
Mattias, Robert and Stefan: any comments on this?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Sat, 05 Aug 2023 23:09:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 65030 <at> debbugs.gnu.org (full text, mbox):
>> The functions make-process and make-network-process have many keyword
>> arguments and it's somewhat easy to misspell some of them. E.g. using
>> :coding-system instead of :coding. These functions don't detect such
>> mistakes at runtime. What would people think about adding some checks
>> as a compiler macro as with the patch below?
Good idea, thanks.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Sun, 06 Aug 2023 04:58:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 65030 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Helmut Eller <eller.helmut <at> gmail.com>, Mattias Engdegård
> <mattiase <at> acm.org>, Robert Pluim <rpluim <at> gmail.com>,
> 65030 <at> debbugs.gnu.org
> Date: Sat, 05 Aug 2023 19:07:53 -0400
>
> >> The functions make-process and make-network-process have many keyword
> >> arguments and it's somewhat easy to misspell some of them. E.g. using
> >> :coding-system instead of :coding. These functions don't detect such
> >> mistakes at runtime. What would people think about adding some checks
> >> as a compiler macro as with the patch below?
>
> Good idea, thanks.
Any specific comments to the proposed patch? Or do you think it is
good to go?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Sun, 06 Aug 2023 08:51:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 65030 <at> debbugs.gnu.org (full text, mbox):
6 aug. 2023 kl. 06.58 skrev Eli Zaretskii <eliz <at> gnu.org>:
> Any specific comments to the proposed patch? Or do you think it is
> good to go?
Good to go as far as I'm concerned. It will be genuinely useful, and I see no serious problems with the implementation.
It can be extended but that would not prevent it from being committed as-is. For example, something that detects omitted values in the middle, not just the end, of the argument list. (The feasibility of this depends on the likelihood of argument values being keywords themselves.)
The main objection is that `make-process`, due to its design, is often called indirectly using `apply` which would not trigger the application of this compiler macro, so perhaps we should improve the error handling of Fmake_process instead.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Tue, 08 Aug 2023 08:53:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 65030 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sun, 6 Aug 2023 10:49:59 +0200, Mattias Engdegård <mattiase <at> acm.org> said:
Mattias> 6 aug. 2023 kl. 06.58 skrev Eli Zaretskii <eliz <at> gnu.org>:
>> Any specific comments to the proposed patch? Or do you think it is
>> good to go?
Mattias> Good to go as far as I'm concerned. It will be genuinely useful, and I
Mattias> see no serious problems with the implementation.
Mattias> It can be extended but that would not prevent it from being committed
Mattias> as-is. For example, something that detects omitted values in the
Mattias> middle, not just the end, of the argument list. (The feasibility of
Mattias> this depends on the likelihood of argument values being keywords
Mattias> themselves.)
I donʼt think any of the `make-process' keywords accept keywords as
values, but missing values tends to cause catastrophic failure, so I
donʼt think itʼs that common a mistake.
Mattias> The main objection is that `make-process`, due to its design, is often
Mattias> called indirectly using `apply` which would not trigger the
Mattias> application of this compiler macro, so perhaps we should improve the
Mattias> error handling of Fmake_process instead.
As long as that improvement results in warnings for mistakes such as
misspelled keywords, rather than errors.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Tue, 08 Aug 2023 09:17:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 65030 <at> debbugs.gnu.org (full text, mbox):
8 aug. 2023 kl. 10.52 skrev Robert Pluim <rpluim <at> gmail.com>:
> I donʼt think any of the `make-process' keywords accept keywords as
> values, but missing values tends to cause catastrophic failure, so I
> donʼt think itʼs that common a mistake.
No, the usefulness of good compiler warnings goes far beyond that. A determined programmer may eventually get something working despite an error-prone API, but decent diagnostics will speed up the process manifold by pointing out mistakes before the code is even run. (With flymake/flycheck, even faster.)
> Mattias> The main objection is that `make-process`, due to its design, is often
> Mattias> called indirectly using `apply` which would not trigger the
> Mattias> application of this compiler macro, so perhaps we should improve the
> Mattias> error handling of Fmake_process instead.
>
> As long as that improvement results in warnings for mistakes such as
> misspelled keywords, rather than errors.
Of course not. Incorrect arguments detected at run-time should elicit errors, as they do now.
The point being that for something as complex as make-process they should be more helpful than just `wrong-type-argument`.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Tue, 08 Aug 2023 09:28:03 GMT)
Full text and
rfc822 format available.
Message #26 received at 65030 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 8 Aug 2023 11:16:07 +0200, Mattias Engdegård <mattiase <at> acm.org> said:
>>
>> As long as that improvement results in warnings for mistakes such as
>> misspelled keywords, rather than errors.
Mattias> Of course not. Incorrect arguments detected at run-time
Mattias> should elicit errors, as they do now. The point being
Mattias> that for something as complex as make-process they should
Mattias> be more helpful than just `wrong-type-argument`.
You want to transform working code that passes ':coding-system' to
`make-process' into code that signals an error? (yes, it doesnʼt work
100% as the programmer thinks it does, but that means we should warn,
not error).
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Tue, 08 Aug 2023 09:43:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 65030 <at> debbugs.gnu.org (full text, mbox):
8 aug. 2023 kl. 11.27 skrev Robert Pluim <rpluim <at> gmail.com>:
> You want to transform working code that passes ':coding-system' to
> `make-process' into code that signals an error?
That's probably a good idea (unless we are talking about a specific keyword that has to be ignored for compatibility), but I think we should start by improving existing errors.
However it should not preclude compile-time warnings of the kind proposed in the patch, which again can be applied more or less as-is.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Tue, 08 Aug 2023 12:17:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 65030 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Tue, 8 Aug 2023 11:16:07 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> eller.helmut <at> gmail.com, 65030 <at> debbugs.gnu.org
>
> > Mattias> The main objection is that `make-process`, due to its design, is often
> > Mattias> called indirectly using `apply` which would not trigger the
> > Mattias> application of this compiler macro, so perhaps we should improve the
> > Mattias> error handling of Fmake_process instead.
> >
> > As long as that improvement results in warnings for mistakes such as
> > misspelled keywords, rather than errors.
>
> Of course not. Incorrect arguments detected at run-time should elicit errors, as they do now.
> The point being that for something as complex as make-process they should be more helpful than just `wrong-type-argument`.
Misspelled arguments to make-process don't elicit errors as of now, do
they?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Tue, 08 Aug 2023 13:06:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 65030 <at> debbugs.gnu.org (full text, mbox):
8 aug. 2023 kl. 14.16 skrev Eli Zaretskii <eliz <at> gnu.org>:
> Misspelled arguments to make-process don't elicit errors as of now, do
> they?
No and that would be good to fix as well, but we should first make existing errors understandable.
For example, (wrong-type-argument stringp nil) is not a human-readable way to say "You forgot the :name parameter which is actually mandatory despite the docs making this almost impossible to find out"
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Tue, 08 Aug 2023 13:19:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 65030 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 8 Aug 2023 15:05:06 +0200, Mattias Engdegård <mattiase <at> acm.org> said:
Mattias> 8 aug. 2023 kl. 14.16 skrev Eli Zaretskii <eliz <at> gnu.org>:
>> Misspelled arguments to make-process don't elicit errors as of now, do
>> they?
Mattias> No and that would be good to fix as well, but we should
Mattias> first make existing errors understandable.
Mattias> For example, (wrong-type-argument stringp nil) is not a
Mattias> human-readable way to say "You forgot the :name parameter
Mattias> which is actually mandatory despite the docs making this
Mattias> almost impossible to find out"
Youʼll get no objections from me for that. Perhaps we need a
CHECK_STRING_WITH_MESSAGE macro or similar.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Tue, 08 Aug 2023 13:38:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 65030 <at> debbugs.gnu.org (full text, mbox):
[Tuesday August 08, 2023] Robert Pluim wrote:
>>>>>> On Sun, 6 Aug 2023 10:49:59 +0200, Mattias Engdegård <mattiase <at> acm.org> said:
>
> Mattias> 6 aug. 2023 kl. 06.58 skrev Eli Zaretskii <eliz <at> gnu.org>:
> >> Any specific comments to the proposed patch? Or do you think it is
> >> good to go?
>
> Mattias> Good to go as far as I'm concerned. It will be genuinely useful, and I
> Mattias> see no serious problems with the implementation.
>
> Mattias> It can be extended but that would not prevent it from being committed
> Mattias> as-is. For example, something that detects omitted values in the
> Mattias> middle, not just the end, of the argument list. (The feasibility of
> Mattias> this depends on the likelihood of argument values being keywords
> Mattias> themselves.)
>
> I donʼt think any of the `make-process' keywords accept keywords as
> values, but missing values tends to cause catastrophic failure, so I
> donʼt think itʼs that common a mistake.
Can you not pass keywords as non-nil values to :query and :stop?
Something like,
(make-process :name NAME :command COMMAND :query :yes)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Tue, 08 Aug 2023 13:54:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 65030 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 08 Aug 2023 19:07:32 +0530, Visuwesh <visuweshm <at> gmail.com> said:
Visuwesh> [Tuesday August 08, 2023] Robert Pluim wrote:
>>>>>>> On Sun, 6 Aug 2023 10:49:59 +0200, Mattias Engdegård <mattiase <at> acm.org> said:
>>
Mattias> 6 aug. 2023 kl. 06.58 skrev Eli Zaretskii <eliz <at> gnu.org>:
>> >> Any specific comments to the proposed patch? Or do you think it is
>> >> good to go?
>>
Mattias> Good to go as far as I'm concerned. It will be genuinely useful, and I
Mattias> see no serious problems with the implementation.
>>
Mattias> It can be extended but that would not prevent it from being committed
Mattias> as-is. For example, something that detects omitted values in the
Mattias> middle, not just the end, of the argument list. (The feasibility of
Mattias> this depends on the likelihood of argument values being keywords
Mattias> themselves.)
>>
>> I donʼt think any of the `make-process' keywords accept keywords as
>> values, but missing values tends to cause catastrophic failure, so I
>> donʼt think itʼs that common a mistake.
Visuwesh> Can you not pass keywords as non-nil values to :query and :stop?
Visuwesh> Something like,
Visuwesh> (make-process :name NAME :command COMMAND :query :yes)
Only because :yes is non-nil. Also the docstring says:
:noquery BOOL -- When exiting Emacs, query the user if BOOL is nil and
the process is running. If BOOL is not given, query before exiting.
which implies you can say
(make-process :name "foo" :noquery :stop nil)
which is not true, since :noquery is checked with `plist-get'.
Whilst weʼre at it, this is inaccurate as well:
:stop BOOL -- BOOL must be nil. The `:stop' key is ignored otherwise
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
since the following will error:
(make-process :name "foo" :command "ls" :stop t)
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Tue, 08 Aug 2023 16:39:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 65030 <at> debbugs.gnu.org (full text, mbox):
Pushed to master: the warning patch (thank you!) and a modest :name error improvement. This should make things a lot better than they used to be.
Are we done for now?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Tue, 08 Aug 2023 17:16:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 65030 <at> debbugs.gnu.org (full text, mbox):
On Tue, Aug 08 2023, Mattias Engdegård wrote:
> Pushed to master: the warning patch (thank you!) and a modest :name
> error improvement. This should make things a lot better than they used
> to be.
Thank you.
> Are we done for now?
Just a nitpick: (make-process) with 0 arguments doesn't signal a runtime
error. The
if (nargs == 0)
return Qnil;
is now probably counterproductive.
Helmut
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Tue, 08 Aug 2023 17:44:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 65030 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Tue, 8 Aug 2023 18:38:03 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca,
> eller.helmut <at> gmail.com, 65030 <at> debbugs.gnu.org
>
> Pushed to master: the warning patch (thank you!) and a modest :name error improvement. This should make things a lot better than they used to be.
>
> Are we done for now?
I wish: the build is now broken:
Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name bootstrap-emacs.pdmp
Dumping fingerprint: 7776ea71b2c2039613aeb93d6ca789f55809907a652a1c1d86e6cbdb881
5025a
Dump complete
Byte counts: header=100 hot=16245400 discardable=136576 cold=11545712
Reloc counts: hot=1160567 discardable=5641
ANCIENT=yes make -C ../lisp compile-first EMACS="../src/bootstrap-emacs.exe"
make[3]: Entering directory `/d/gnu/git/emacs/trunk/lisp'
ELC emacs-lisp/macroexp.elc
ELC emacs-lisp/cconv.elc
ELC emacs-lisp/byte-opt.elc
ELC emacs-lisp/bytecomp.elc
ELC emacs-lisp/loaddefs-gen.elc
ELC emacs-lisp/radix-tree.elc
In toplevel form:
emacs-lisp/loaddefs-gen.el:42:2: Error: Eager macro-expansion failure: (void-variable name)
Makefile:333: recipe for target `emacs-lisp/loaddefs-gen.elc' failed
make[3]: *** [emacs-lisp/loaddefs-gen.elc] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory `/d/gnu/git/emacs/trunk/lisp'
Makefile:1011: recipe for target `bootstrap-emacs.pdmp' failed
make[2]: *** [bootstrap-emacs.pdmp] Error 2
make[2]: Leaving directory `/d/gnu/git/emacs/trunk/src'
Makefile:554: recipe for target `src' failed
make[1]: *** [src] Error 2
And this is _after_ deleting emacs, bootstrap-emacs, and temacs, and
deleting all the *.elc files. So no stale *.elc files are involved, I
think.
(And no, I don't want to bootstrap, and I don't think it will fix the
problem, given the above.)
Line 42 of loaddefs-gen.el is where it require's lisp-mnt, FWIW.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Tue, 08 Aug 2023 17:52:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 65030 <at> debbugs.gnu.org (full text, mbox):
8 aug. 2023 kl. 19.43 skrev Eli Zaretskii <eliz <at> gnu.org>:
> I wish: the build is now broken:
So very sorry, I'll deal with it right away (and revert if a timely remedy isn't possible).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Tue, 08 Aug 2023 17:55:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 65030 <at> debbugs.gnu.org (full text, mbox):
> Line 42 of loaddefs-gen.el is where it require's lisp-mnt, FWIW.
That's my bad, should be fixed now.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Tue, 08 Aug 2023 18:29:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 65030 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Tue, 8 Aug 2023 19:54:29 +0200
> Cc: Mattias Engdegård <mattiase <at> acm.org>, rpluim <at> gmail.com,
> 65030 <at> debbugs.gnu.org, eller.helmut <at> gmail.com, monnier <at> iro.umontreal.ca
>
> > Line 42 of loaddefs-gen.el is where it require's lisp-mnt, FWIW.
>
> That's my bad, should be fixed now.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65030; Package
emacs.
(Tue, 08 Aug 2023 20:16:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 65030 <at> debbugs.gnu.org (full text, mbox):
8 aug. 2023 kl. 19.14 skrev Helmut Eller <eller.helmut <at> gmail.com>:
> Just a nitpick: (make-process) with 0 arguments doesn't signal a runtime
> error. The
>
> if (nargs == 0)
> return Qnil;
>
> is now probably counterproductive.
Always was, and undocumented.
This bug report was last modified 1 year and 316 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.