From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#6415: [PATCH] fix edebug instrumentation of dotted pairs in macros Date: Mon, 26 Sep 2011 21:43:46 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1317087865 7515 80.91.229.12 (27 Sep 2011 01:44:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 27 Sep 2011 01:44:25 +0000 (UTC) Cc: 6415@debbugs.gnu.org To: Steve Yegge Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 27 03:44:21 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R8Mia-0008OM-N7 for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Sep 2011 03:44:20 +0200 Original-Received: from localhost ([::1]:59999 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8Mia-0007rB-Ac for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Sep 2011 21:44:20 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:38594) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8MiY-0007qv-1L for bug-gnu-emacs@gnu.org; Mon, 26 Sep 2011 21:44:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R8MiW-0005jp-Pg for bug-gnu-emacs@gnu.org; Mon, 26 Sep 2011 21:44:17 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60882) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8MiW-0005jl-Mr for bug-gnu-emacs@gnu.org; Mon, 26 Sep 2011 21:44:16 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1R8MjG-0007DT-S3 for bug-gnu-emacs@gnu.org; Mon, 26 Sep 2011 21:45:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 27 Sep 2011 01:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6415 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 6415-submit@debbugs.gnu.org id=B6415.131708787827690 (code B ref 6415); Tue, 27 Sep 2011 01:45:02 +0000 Original-Received: (at 6415) by debbugs.gnu.org; 27 Sep 2011 01:44:38 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R8Mir-0007CZ-I6 for submit@debbugs.gnu.org; Mon, 26 Sep 2011 21:44:37 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R8Mio-0007CS-LX for 6415@debbugs.gnu.org; Mon, 26 Sep 2011 21:44:35 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJkpgU5FpZLc/2dsb2JhbABCp295gVMBAQQBViMFCws0EhQYDSSIC7oRhwsEoF6EQw X-IronPort-AV: E=Sophos;i="4.68,447,1312171200"; d="scan'208";a="138652641" Original-Received: from 69-165-146-220.dsl.teksavvy.com (HELO ceviche.home) ([69.165.146.220]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 26 Sep 2011 21:43:47 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id E40E7660B6; Mon, 26 Sep 2011 21:43:46 -0400 (EDT) In-Reply-To: (Steve Yegge's message of "Mon, 26 Sep 2011 10:17:52 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 26 Sep 2011 21:45:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) 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:51906 Archived-At: > It so happens that the `cl-macro-list1' edebug-spec does all three > of these things properly. I haven't looked into it, so I'll trust on that one. > The second problem is in edebug. The unification algorithm has > improper or missing handling for dotted pairs in specs. I chose > to add the handling to `edebug-match-specs' since it seemed to be > the cleanest place to insert it. This edebug-dotted-spec business is really ugly, I wonder if/how we could just get rid of this variable. Or at least document clearly what it is supposed to mean. > - ;; Is the form dotted? > - ((not (listp (edebug-cursor-expressions cursor)));; allow nil > + ;; Special handling for the tail of a dotted form. > + ((and > + ;; Is the cursor on the tail of a dotted form? > + (not (listp (edebug-cursor-expressions cursor)));; allow nil > + ;; When matching a dotted form such as (a b . c) against a > + ;; spec list that looks like > + ;; ([&rest ...] [&optional ...]+ . [&or arg nil]) > + ;; ,e.g., the `cl-macro-list1' edebug-spec, then the &rest spec > + ;; will consume everything up to the dotted tail (`c' in this > + ;; example). At that point the spec list will look like so: > + ;; ([&optional ...]+ . [&or arg nil]) > + ;; We need to be able to consume zero or more [&optional ...] > + ;; spec(s) without moving the cursor or signaling an error. > + ;; The current continuation provides no state that tells us > + ;; about the upcoming &optional specs, so we use lookahead: > + > + ;; Recurse normally if we're about to process an optional spec. > + (not (eq (car specs) '&optional)) > + ;; Recurse normally if the spec is a dotted list. > + (not (and (listp specs) > + (not (listp (cdr (last specs))))))) > + ;; Otherwise we need to be on the tail of a dotted spec. > (if (not edebug-dotted-spec) > (edebug-no-match cursor "Dotted spec required.")) > ;; Cancel dotted spec and dotted form. Questions: - Should it really only be &optional? it looks like any &foo might work just as well. Also shouldn't we check the (eq (aref (car specs) 0) '&optional) instead? - What's the purpose of the (not (and (listp specs) (not (listp (cdr (last specs))))))? For one (listp specs) will always be t (we've checked (atom specs) earlier and we've just called (car specs) on the previous line) so the code is really (not (and t (not (listp (cdr (last specs)))))) aka (listp (cdr (last specs))) but if the car of specs is not an &optional, then we have a mismatch anyway, no? Stefan