From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Gemini Lasswell Newsgroups: gmane.emacs.bugs Subject: bug#31090: 26.0.91; Edebug incorrectly instruments unquotes in nested backquotes Date: Wed, 11 Apr 2018 07:15:45 -0700 Message-ID: <878t9tvnfy.fsf@runbox.com> References: <20180409191541.86928.qmail@mail.muc.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1523456110 13921 195.159.176.226 (11 Apr 2018 14:15:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 11 Apr 2018 14:15:10 +0000 (UTC) User-Agent: mu4e 0.9.18; emacs 26.0.91 Cc: 31090@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Apr 11 16:15:05 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1f6GWf-0003Tp-AN for geb-bug-gnu-emacs@m.gmane.org; Wed, 11 Apr 2018 16:15:05 +0200 Original-Received: from localhost ([::1]:58592 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f6GYl-0003XH-TO for geb-bug-gnu-emacs@m.gmane.org; Wed, 11 Apr 2018 10:17:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f6GYf-0003Wj-BS for bug-gnu-emacs@gnu.org; Wed, 11 Apr 2018 10:17:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f6GYZ-0005jW-BN for bug-gnu-emacs@gnu.org; Wed, 11 Apr 2018 10:17:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38439) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f6GYY-0005jQ-Sf for bug-gnu-emacs@gnu.org; Wed, 11 Apr 2018 10:17:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f6GYY-0005co-GY for bug-gnu-emacs@gnu.org; Wed, 11 Apr 2018 10:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gemini Lasswell Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Apr 2018 14:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31090 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31090-submit@debbugs.gnu.org id=B31090.152345618621562 (code B ref 31090); Wed, 11 Apr 2018 14:17:02 +0000 Original-Received: (at 31090) by debbugs.gnu.org; 11 Apr 2018 14:16:26 +0000 Original-Received: from localhost ([127.0.0.1]:46336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f6GXy-0005bh-4W for submit@debbugs.gnu.org; Wed, 11 Apr 2018 10:16:26 -0400 Original-Received: from aibo.runbox.com ([91.220.196.211]:46484) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f6GXw-0005bX-Hu for 31090@debbugs.gnu.org; Wed, 11 Apr 2018 10:16:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Type:MIME-Version:Message-ID:Date:In-reply-to: References:Subject:Cc:To:From; bh=vy0+w1RqjX1NYJkuudzS6Zi7YL8gWk5o9wLM5svJndU=; b=ROuJC5IhJ5rnI/d+qlxdppSbV9 CykQu7CkARsRpI6Nnl0IJ90R2NcnnX7qsLlqz2GdrI6eKV/vXzBM5gbbxEvCF4MdkK+t1svTGz/sY L38OQsjs0Im7BzHPXiTnQM6BkUansnWJpg99pLEvGveravqSn//zHCQ1H/ww135STme5gdECxRFol ICzMTxksOWrDUiit/OjwHs6qkWZDi5oa1HwN3atn8PILIVCtQFRqMipPSoG6aVwKxffFmOOXf/lWs 3S3ZbC/DlsHq6eU/fsVBNElE21TtA8787old64sflVJhpDFGnaKgaCzM38fZY3pcwHuWyApCb4wFW woHeemBA==; Original-Received: from [10.9.9.212] (helo=mailfront12.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1f6GXu-0004Ip-UW; Wed, 11 Apr 2018 16:16:23 +0200 Original-Received: from 200.sub-174-206-19.myvzw.com ([174.206.19.200] helo=sockeye) by mailfront12.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1f6GXO-0003wX-G9; Wed, 11 Apr 2018 16:15:51 +0200 In-reply-to: <20180409191541.86928.qmail@mail.muc.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:145075 Archived-At: Hi Alan, > I think we've been here before, in bug #16184. The problem is that the > instrumented form hasn't called edebug-enter, for whatever reason, hence > hasn't pushed a cons onto edebug-offset-indices, which is thus still > nil. The (setcar edebug-offset-indices ...) at the start of > edebug-slow-before (to which edebug-before is aliased) thus fails. Yes, whenever Edebug's instrumentation is malformed due to a bug, edebug-before is where it fails. Consider what edebug-before does: if you are stepping through code, or type a key while running instrumented code, it brings up Edebug's recursive edit at the location the form was defined, the correct buffer, function and offset within the function. In order to do that it relies upon edebug-enter having looked up that information and placed it in Edebug's dynamic variables. > At the time, I committed a solution which involved initialising that > variable to '(0) instead of nil. You persuaded me to revert that > change, saying [Date: Fri, 30 Dec 2016 15:27:37 -0800, Subject: Re: > bug#16184: 24.3.50; edebug and eval-when-compiler don't work together]: > > > I haven't able to reproduce the bug with cc-eval-when-compile, just > > eval-and-compile. But the thing that is supposed to make Edebug wrap a > > form in edebug-enter is the use of def-form or def-body in the Edebug > > spec. It works for eval-when-compile which has the Edebug spec (&rest > > def-form). The body of eval-and-compile doesn't get wrapped because > > its Edebug spec is t, so the bug happens there. > > > cc-eval-when-compile has the same Edebug spec as eval-when-compile, so > > its body should get wrapped by edebug-enter. If that's not happening > > in your Emacs, it's a bug in Edebug which is different from the > > eval-and-compile Edebug spec bug. > > This, if true, implies that using an instrumented macro is liable to > produce this error if that macro doesn't have an appropriate edebug > spec. This seems to be an unreasonable prerequisite - I think the > typical work flow would be writing a macro first, testing it with the > help of Edebug, and then, possibly writing an edebug spec. If a macro, instrumented or not, has no Edebug spec, this error should not happen. Without an Edebug spec, Edebug does not instrument any of the forms that are arguments to the macro, so there shouldn't be any instrumentation in the macro expansion. The fact that `(,,fn ,@,args) is currently making instrumentation show up in the macro expansion is a bug in Edebug. If a macro has an incorrect Edebug spec, it can cause this error, in particular if the spec uses 'form' instead of 'def-form' to describe one of the macro's arguments, and then the macro wraps that form in a lambda and saves it somewhere, and it later gets called outside of its original context. > Perhaps we should think again about my solution from December 2016, > namely initialising edebug-offset-indices to a cons '(0). I've just > tried this, and got the error edebug-freq-count is unbound. So perhaps > we should give initial values to all these declared dynamic variables > which are bound by edebug-enter, for the case when edebug-enter doesn't > get called. This isn't going to work for the reason I described above, because Edebug won't know where to invoke its recursive edit. Changing edebug-before to fail silently when its dynamic variables are unbound would not solve the problem either because if mis-instrumented code is called from a correctly instrumented function, then edebug-before will find that the data in the dynamic variables is wrong instead of missing. For an example of that, go back to the steps to reproduce this bug and evaluate my-test with C-u C-M-x instead of C-M-x, and then run it. The result will be an error message, "Args out of range: [20 31 38 39], 24", because edebug-before is trying to use an index (form number) from my-should in the arrays for my-test, which has fewer forms. If my-test was a longer function with the same or more forms than my-should, then the error would not happen but stepping through my-test with Edebug would do some weird jumping around when it got to the erroneous edebug-before. While pondering this I found a comment in edebug.el saying that the reason for the distinction between form and def-form in the edebug specs for macro arguments was that using def-form everywhere would be expensive. But that was written in 1994, and it doesn't sound prohibitively expensive to me now. I'll give it a try and report back.