bug#71379: closed (29.3; Elisp compiler: warnings for formats given insufficiently many arguments)

[GNU bug Tracking System]

Your message dated Thu, 6 Jun 2024 10:49:07 +0200
with message-id <03B10D9E-2A0A-4E18-B706-730BB2189CED@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@gnu.org.)


-- 
71379: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71379
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
> --- Begin Message ---
>
>
>
> 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'
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> 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@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.
>
>
>
> --- End Message ---