[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lexical byte-compilation warnings cleanup
From: |
Juanma Barranquero |
Subject: |
Re: Lexical byte-compilation warnings cleanup |
Date: |
Tue, 20 Aug 2013 02:01:06 +0200 |
On Tue, Aug 20, 2013 at 1:33 AM, Daniel Hackney <address@hidden> wrote:
> - `condition-case': The byte-compiler doesn't recognize the handler
> Byte-compiling that with `byte-compile-force-lexical-warnings' set
> to `t' warns of "Unused lexical argument `data'". Switching lines 1
> and 2 gives the warning "the function `end-of-file' is not known to
> be defined." Removing line 1 makes it compile without errors. It
> would seem that the byte-compiler is not treating `condition-case'
> as specially as it should.
IIRC, each error form is compiled as a lambda that gets the error
variable as an argument. So if some of them do not use the arg, you
get the lexical-binding warning. It is definitely something that
should be improved (the lexical-binding implementation of this
feature, I mean).
> - I'm seeing a lot of "Argument foo is not a lexical variable", such as
> in vc/ediff-diff.el:532:56. What does this mean and is this something
> I should "fix"? In some cases, this is because `foo' is defined with
> `defvar' but also used as a function argument. What should be done in
> this case? For example, here is the definition of
> `emerge-remote-exit':
I don't think there's a general answer. It depends on how the argument
/ dynamic variable are used.
> - In `emerge-revisions-with-ancestor', the variable `cmd' is let-bound,
> but does not appear to be used. Could it be safely removed?
>
> - Similarly, `cvs-fileinfo<' binds variables `subtypea' and `subtypeb'
> but never uses them. Can they be removed?
>
> - Superfluously-bound variables: In, for example,
> `ange-ftp-file-attributes', the variables `host', `user', and `name'
> are bound but never used. Should these be prefixed with an
> underscore (to make the byte compiler shut up) or removed altogether
> (since they aren't actually used)? It seems like they should just be
> removed, but I don't want to trample on something needed.
Same here. The problem is that in some cases, these variables are
bound to be used in other functions called from the ones that let-bind
them. In a few cases, they are *not* used, but they are declared as
part of the user interface, expecting that the user will use
expressions with these variables that will be eval'ed and expect the
variables to be bound (I think Calc does this, for example).
So, you have to take a hard look, try to find whether these arguments
or let-bindings are used dynamically or not. If not, they can usually
be fixed as you suggest. If they are, in some cases they could also be
fixed (the defvar vs. function arg that you point above), if the
variable name is not part of the defined interface... It's all a big
PITA, and very easy to make a mistake, truth be told.
J
- Lexical byte-compilation warnings cleanup, Daniel Hackney, 2013/08/19
- Re: Lexical byte-compilation warnings cleanup,
Juanma Barranquero <=
- Re: Lexical byte-compilation warnings cleanup, Glenn Morris, 2013/08/19
- Re: Lexical byte-compilation warnings cleanup, Stefan Monnier, 2013/08/20
- RE: Lexical byte-compilation warnings cleanup, Drew Adams, 2013/08/20
- Re: Lexical byte-compilation warnings cleanup, Stefan Monnier, 2013/08/20
- RE: Lexical byte-compilation warnings cleanup, Drew Adams, 2013/08/20
- Re: Lexical byte-compilation warnings cleanup, Stefan Monnier, 2013/08/20
- RE: Lexical byte-compilation warnings cleanup, Drew Adams, 2013/08/20
- RE: Lexical byte-compilation warnings cleanup, Stephen J. Turnbull, 2013/08/20
- RE: Lexical byte-compilation warnings cleanup, Drew Adams, 2013/08/20
- Re: Lexical byte-compilation warnings cleanup, Stefan Monnier, 2013/08/21