From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] feature/byte-unwind-protect 916094a 2/2: Add new bytecodes for unwind-protect Date: Tue, 23 Jan 2018 10:35:31 -0500 Message-ID: References: <20180123051231.6240.43062@vcs0.savannah.gnu.org> <20180123051232.EBBB6207FC@vcs0.savannah.gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1516721762 12070 195.159.176.226 (23 Jan 2018 15:36:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 23 Jan 2018 15:36:02 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Tom Tromey To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 23 16:35:58 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ee0bo-0001fU-D4 for ged-emacs-devel@m.gmane.org; Tue, 23 Jan 2018 16:35:36 +0100 Original-Received: from localhost ([::1]:35993 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ee0do-0002zR-QR for ged-emacs-devel@m.gmane.org; Tue, 23 Jan 2018 10:37:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33437) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ee0bt-00022I-7K for emacs-devel@gnu.org; Tue, 23 Jan 2018 10:35:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ee0bo-0006Gw-7U for emacs-devel@gnu.org; Tue, 23 Jan 2018 10:35:41 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:35421) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ee0bn-0006Dc-UI for emacs-devel@gnu.org; Tue, 23 Jan 2018 10:35:36 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w0NFZVaX026846; Tue, 23 Jan 2018 10:35:31 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 40B1960782; Tue, 23 Jan 2018 10:35:31 -0500 (EST) In-Reply-To: <20180123051232.EBBB6207FC@vcs0.savannah.gnu.org> (Tom Tromey's message of "Tue, 23 Jan 2018 00:12:32 -0500 (EST)") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6206=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6206> : inlines <6332> : streams <1776876> : uri <2577619> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:222168 Archived-At: > + (if (not byte-compile--use-old-handlers) > + (let ((except-tag (byte-compile-make-tag))) [...] > + (pcase (cddr form) > + (`(:fun-body ,f) > + (byte-compile-form > + (if byte-compile--use-old-handlers `(list (list 'funcall ,f)) f))) > + (handlers > + (if byte-compile--use-old-handlers Clearly the last two tests of byte-compile--use-old-handlers can be dropped since they're inside a branch where we know byte-compile--use-old-handlers is t. BTW, when introducing byte-codes we've "traditionally" done it in two steps: - in release N we add the code which handles the new byte-codes, and we add support for the new byte-code in the byte-compiler, but disabled by default. - in release N+1 we enable the use of the new byte-codes in the byte-compiler by default. This is done so as to reduce the pain when running a file compiled with another Emacs version. But we don't want to set byte-compile--use-old-handlers back to nil for your new bytecodes, so better use another variable. Also byte-compile--use-old-handlers can be retired, I think, because it has played its role. > + CASE (Bpushunwindprotect): /* New in 27.1. */ > + { > + struct handler *c = push_handler (Qt, CATCHER_ALL); Hmm... using this "catch+rethrow" method interferes with the debug-on-error stacktrace: (defun sm-test-1 () (unwind-protect (sm-test-2) (message "hello"))) (defun sm-test-2 () (message "test-1-in") (car 4)) (setq debug-on-error t) then call `sm-test-1` and you'll see that Emacs gives you a backtrace that gives the impression the error was signaled in `sm-test-1`! I also wonder if there can be places where we call something like `unbind_to` which should run those new unwind-forms but won't find it because it won't look at the handlers [ offhand, I can't think of any place where that would happen, and I think it's probably OK, but I can't quite convince myself that it definitely is. ] All in all, I'd really prefer if we kept the unwind forms in the specpdl. Was there a particular reason why you used the handlers instead? Stefan