GNU bug report logs - #71379
29.3; Elisp compiler: warnings for formats given insufficiently many arguments

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#71379: closed (29.3; Elisp compiler: warnings for formats
 given insufficiently many arguments)
Date: Thu, 06 Jun 2024 08:51:01 +0000

[Message part 1 (text/plain, inline)]

Your message dated Thu, 6 Jun 2024 10:49:07 +0200
with message-id <03B10D9E-2A0A-4E18-B706-730BB2189CED <at> gmail.com>
and subject line Re: bug#71379: 29.3; Elisp compiler: warnings for formats given insufficiently many arguments
has caused the debbugs.gnu.org bug report #71379,
regarding 29.3; Elisp compiler: warnings for formats given insufficiently many arguments
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
71379: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71379
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Philippe Schnoebelen <phs <at> lmf.cnrs.fr>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.3; Elisp compiler: warnings for formats given insufficiently many
 arguments
Date: Wed, 5 Jun 2024 15:16:16 +0200

The following example code has been put in my ~/foo.el

(defun check-value (v)
  ;; Let's demonstrate different treament of formats by elisp compiler
  (cond (v
	 (print (format "Congratulations! v=%S is non-NIL."))
	 ;; oops, we forgot to pass v in `format's &rest args
	 t)
	(t ;; otherwise
	 (user-error "Try again. v=%S is null")
	 ;; same error, here when calling `user-error'
	 nil)))


When I byte-compile it with M-x byte-compile-file I get the following 
warning message:

     In check-value:
     foo.el:4:18: Warning: ‘format’ called with 0 args to fill 1 format 
field(s)

which is very useful.

But why don't I get a similar error message for my call to user-error ? 
It would be useful too.

Note that when I evaluate (check-value nil) I get an error with the 
following *Backtrace*, showing that my call to
`user-error' fails for exactly the same reason that evaluating 
`(check-value t)' fails.

Debugger entered--Lisp error: (error "Not enough arguments for format 
string")
  format-message("Try again. v=%S is null")
  apply(format-message "Try again. v=%S is null" nil)
  user-error("Try again. v=%S is null")
  (if v (print (format "Congratulations! v=%S is non-NIL.")) 
(user-error "Try again. v=%S is null"))
  check-value(nil)
  (progn (check-value nil))
  eval((progn (check-value nil)) t)
  elisp--eval-last-sexp(t)
  eval-last-sexp(t)
  eval-print-last-sexp(nil)
  funcall-interactively(eval-print-last-sexp nil)
  call-interactively(eval-print-last-sexp nil nil)

I thought you'd like to know.

Thanks for your time and dedication in developing GNU Emacs !

--philippe

In GNU Emacs 29.3 (build 1, aarch64-apple-darwin21.6.0, NS 
appkit-2113.60 Version 12.6.6 (Build 21G646)) of
 2024-03-24 built on armbob.lan
Windowing system distributor 'Apple', version 10.3.2487
System Description:  macOS 14.5

Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application 
Support/Emacs/site-lisp' --with-modules
 'CFLAGS=-DFD_SETSIZE=10000 -DDARWIN_UNLIMITED_SELECT' --with-x-toolkit=no'

[Message part 3 (message/rfc822, inline)]

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71379-done <at> debbugs.gnu.org, philippe schnoebelen <schnoebelen.ph <at> gmail.com>
Subject: Re: bug#71379: 29.3; Elisp compiler: warnings for formats given
 insufficiently many arguments
Date: Thu, 6 Jun 2024 10:49:07 +0200

6 juni 2024 kl. 06.38 skrev Eli Zaretskii <eliz <at> gnu.org>:

> On second thought, this is still fine to go in now, but I wonder
> whether we should move these to the places where the corresponding
> functions are defined, and leave in bytecomp.c only those which are
> primitives defined in C?  That would mean 'warn' and 'user-error'
> should be moved to their respective Lisp files.

Indeed it's a question I always ask myself every so often, and sometimes we distribute properties to definitions. 
However, in this case it seems better to keep them in one place: it's only a small handful of functions, and this way the properties are kept local to the byte-compiler.

Thank you, the change is now on master. Closing.

Previous Next

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