bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18014: 24.3; Unused Lexical argument warning, when argument is used


From: Eli Zaretskii
Subject: bug#18014: 24.3; Unused Lexical argument warning, when argument is used in a function...
Date: Tue, 15 Jul 2014 17:18:53 +0300

> Date: Mon, 14 Jul 2014 14:46:04 -0500
> From: Matthew Fidler <matthew.fidler@gmail.com>
> Cc: 18014@debbugs.gnu.org
> 
> Easy enough.  Put these in a directory, say ~/emacs-bug-1801 and run the
> following command:
> 
> emacs -Q --batch -L . --eval             \
>      "(progn                                \
>        (setq byte-compile-error-on-warn t)  \
>        (batch-byte-compile))" *.el
> 
> 
> On Emacs 24.3 the following warning will occur:
> 
> In toplevel form:
> bug.el:10:1:Warning: Unused lexical argument `key' *<<--- Incorrect; key is
> a used lexical argument*

The line number in this warning is a lie: the problem is in the lambda
function:

       (lambda(key plist)
         (setq ret (ergoemacs-translation-install plist orig-key ret)))

which does leave its 'key' argument unused.  (If you rename this
argument to something else, leaving the rest of ergoemacs-translate
with the original 'key', the warning will reference the new name.)

> Also on emacs 24.3, even though batch-byte-compile-error-on-warn is set to
> t, it will ignore the errors, which is not what I expect when I set this
> option.
> On Emacs trunk (24.4) it will not ignore the error but cause the make to
> fail.

The last observation doesn't match what I see here: when I compile
bug.el with the current trunk, Emacs issues the warning, not error,
message, and exits with exit code of zero.  Which matches what I see
in the code: the warning about unused lexical argument is issued (in
cconv.el) by calling byte-compile-log-warning, which bypasses the
machinery that converts byte-compile warnings to errors; not sure if
this is on purpose or not.

So if you see something different, there's some other factor(s) at
work here.

In any case, this is a separate issue, which probably warrants a
separate report.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]