From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#15122: 24.3.50; [PATCH] byte-compiler warnings about destructive functions Date: Sun, 18 Aug 2013 22:07:14 -0700 (PDT) Message-ID: <189c1f04-03cf-4dbb-b8ac-b190a774788c@default> References: <9ee2e7bb-6036-4e81-bb44-86d4ac74e7b8@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1376888903 30520 80.91.229.3 (19 Aug 2013 05:08:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Aug 2013 05:08:23 +0000 (UTC) Cc: 15122@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Aug 19 07:08:22 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1VBHhW-0006xK-04 for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Aug 2013 07:08:22 +0200 Original-Received: from localhost ([::1]:40907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBHhV-0001wn-HU for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Aug 2013 01:08:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55589) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBHhK-0001mL-Px for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2013 01:08:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBHhD-0007Ap-2P for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2013 01:08:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45214) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBHhC-0007Aj-V9 for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2013 01:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VBHhC-0003Ph-Bg for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2013 01:08:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Aug 2013 05:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15122 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 15122-submit@debbugs.gnu.org id=B15122.137688884913073 (code B ref 15122); Mon, 19 Aug 2013 05:08:02 +0000 Original-Received: (at 15122) by debbugs.gnu.org; 19 Aug 2013 05:07:29 +0000 Original-Received: from localhost ([127.0.0.1]:39530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBHgf-0003On-6w for submit@debbugs.gnu.org; Mon, 19 Aug 2013 01:07:29 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:50054) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBHgc-0003OS-0i for 15122@debbugs.gnu.org; Mon, 19 Aug 2013 01:07:27 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7J57I6L031908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Aug 2013 05:07:19 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7J57H2P022161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 05:07:18 GMT Original-Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7J57GaB005748; Mon, 19 Aug 2013 05:07:17 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:77490 Archived-At: > > This StackOverflow entry suggested that the Emacs-Lisp byte compiler be > > able to warn about the use of functions that are destructive, i.e., can > > modify data structures in place: > > http://stackoverflow.com/questions/17610046/elisp-destructive-operation= - > > warning Attached is a patch that provides this, at least a start. >=20 > All of those functions are used on a regular basis in perfectly > correct code. So just flagging every call is not going to fly. We need > to have some further analysis so that we don't flag all calls, but only > those that "could be dangerous". >=20 > As it stands, your code would just flood you with false positives, > so it wouldn't really help you find the problematic uses. That was not the aim. The question was not whether particular code that uses a destructive operation is correct. The question was whether particular code uses a destructive operation at all. That's all. See the OP, which spoke of an "elisp-newbie-mode". He requested a feature that "adds warnings about destructive operations being used". Not being used wrongly or problematically, just being used. Anyway, I would agree that warning about use of a destructive function should be turned off by default. It's also fine with me if you ignore the patch altogether. I can see a use for such a warning, as I expect there are a fair number of people who want to avoid using destructive operations in general and might not be aware of when they might be doing so. I mentioned Scheme's explicit choice to name all such functions in a noticeable way. Drawing attention to (all) use of destructive operations is not necessarily a useless thing, depending on the user and context. That was the point of the patch. It was not to detect uses that are "problematic", such as where you forget to use `setq' after `delq' to store the result back into the source variable, or similar. (Yes, it is true that the OP example was such a case.)