From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: Lexical byte-compilation warnings cleanup Date: Tue, 20 Aug 2013 02:01:06 +0200 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1376956912 25259 80.91.229.3 (20 Aug 2013 00:01:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Aug 2013 00:01:52 +0000 (UTC) Cc: Emacs development discussions To: Daniel Hackney Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 20 02:01:55 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VBZOU-00084A-Re for ged-emacs-devel@m.gmane.org; Tue, 20 Aug 2013 02:01:55 +0200 Original-Received: from localhost ([::1]:45321 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBZOU-0001yw-Fr for ged-emacs-devel@m.gmane.org; Mon, 19 Aug 2013 20:01:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48045) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBZOQ-0001yl-09 for emacs-devel@gnu.org; Mon, 19 Aug 2013 20:01:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBZOP-0003Xl-0U for emacs-devel@gnu.org; Mon, 19 Aug 2013 20:01:49 -0400 Original-Received: from mail-ee0-x229.google.com ([2a00:1450:4013:c00::229]:50597) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBZOO-0003XX-QT for emacs-devel@gnu.org; Mon, 19 Aug 2013 20:01:48 -0400 Original-Received: by mail-ee0-f41.google.com with SMTP id d17so2457493eek.28 for ; Mon, 19 Aug 2013 17:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=79KVOpwXjNspBc5v/YjEaDSVUV3bniNvFkFsetyHQq4=; b=O+PM7RUrBYsYhhE7hgCGY5vK9WMbHVJNDDqxFSvT031Z9+qvkYBKw9kkyNW9JhBMes +9IauyCco2yaQFJbqagL6K+yWJCWYegkyDVtj9gFemHt6fdE6+n1L4HDWUZAHtELKrxH dp+Iy9fqQWU6l8hGau6nDlOCDPw5SlARtnZdTwe9GzuAEob5aXsPJQlnfU/RpuVnT5D4 VewF/MfIqycC3q17ctn3NrYa/STf59H71jN1ujV9qR9B0R6hzGXywhXYxmx35j2Zk4RR ftGITxF5XoDYMAtUkN+pDxRWsiS3+ndVbpOTfLc0OhYpNFGLaBVoIcJHNVtnMMSzDv9E Rn4g== X-Received: by 10.14.184.3 with SMTP id r3mr8487189eem.49.1376956907285; Mon, 19 Aug 2013 17:01:47 -0700 (PDT) Original-Received: by 10.14.133.15 with HTTP; Mon, 19 Aug 2013 17:01:06 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:162899 Archived-At: On Tue, Aug 20, 2013 at 1:33 AM, Daniel Hackney 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