From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alex Newsgroups: gmane.emacs.bugs Subject: bug#24402: should-error doesn't catch all errors Date: Thu, 13 Jul 2017 22:42:10 -0600 Message-ID: <87d193ljdp.fsf@lylat> References: <3654D8E9-D3CB-402B-922F-B132C1871E9F@runbox.com> <596E65D2-E780-43A1-A75B-603B61B6F9F4@runbox.com> <87zickhoco.fsf_-_@lylat> <877eznda7v.fsf@lylat> <874lur0zki.fsf@calancha-pc> <87o9sywtbz.fsf@lylat> <87fue3f9p8.fsf@users.sourceforge.net> <87vamyl3j3.fsf@lylat> <87tw2het1b.fsf@users.sourceforge.net> <874luhbo4l.fsf@lylat> <87lgntdswo.fsf@users.sourceforge.net> <87k23d9gvt.fsf@lylat> <87d195dmr0.fsf@users.sourceforge.net> <87lgns7y7g.fsf@lylat> <877ezbew3d.fsf@users.sourceforge.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1500007400 29637 195.159.176.226 (14 Jul 2017 04:43:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Jul 2017 04:43:20 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: Gemini Lasswell , 24402@debbugs.gnu.org, Tino Calancha To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 14 06:43:16 2017 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 1dVsRe-0007P1-VJ for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Jul 2017 06:43:15 +0200 Original-Received: from localhost ([::1]:35392 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVsRk-0000tn-El for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Jul 2017 00:43:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVsRa-0000sv-63 for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2017 00:43:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVsRS-0001RN-Pc for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2017 00:43:10 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34923) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dVsRS-0001R1-KE for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2017 00:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dVsRS-00072A-4M for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2017 00:43:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alex Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Jul 2017 04:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed patch Original-Received: via spool by 24402-submit@debbugs.gnu.org id=B24402.150000734726994 (code B ref 24402); Fri, 14 Jul 2017 04:43:02 +0000 Original-Received: (at 24402) by debbugs.gnu.org; 14 Jul 2017 04:42:27 +0000 Original-Received: from localhost ([127.0.0.1]:37600 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dVsQt-00071K-JS for submit@debbugs.gnu.org; Fri, 14 Jul 2017 00:42:27 -0400 Original-Received: from mail-it0-f66.google.com ([209.85.214.66]:34528) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dVsQs-000715-DJ for 24402@debbugs.gnu.org; Fri, 14 Jul 2017 00:42:26 -0400 Original-Received: by mail-it0-f66.google.com with SMTP id o202so10785312itc.1 for <24402@debbugs.gnu.org>; Thu, 13 Jul 2017 21:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=tbKbpU4GH0bBQr9LVi8tI9dQrPTtACr4cTVUi5/pEtY=; b=k0t4v8KqWcmI0oHXJf1OIGivHbcWWuttO4YbV15N8tZRfkMNufmowv4Xut+S8d0k5D w3UQN44UU3jawQPwmkCpyLZA8KCo7DD213L2u3X8HsHGULcVAIJ7EPu6FQBZEbCvVlBG g7IGGV5s5DDICSc7MHuFPd8CTNJC7nBpjuUT7fVk2Bedg3ztWFCMSSuQR9shBX3rb07/ 76a0S9Ehou9psuNVir7+7WWC9EcSveZki4A8G0pxtSHrqqkaAqrEO3yQ0zdeg5c3Y96e TInVnw/s2sxbGZ7YaBfHU4BJW8gVd1JBftE86HN2QHEc3hvZ3KZDvsBhdgr3l/X0ifH4 /TJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=tbKbpU4GH0bBQr9LVi8tI9dQrPTtACr4cTVUi5/pEtY=; b=BAm9m3IbvCjpAEg1iG0aVxBm37tuzOON4hUOu4aU2W2ZwykV+k2ozslF1L8Njlnmqo /wR/nubGE7VbBzSXotA7ydIkfJB4oDKzJqNirBOEebIinJOpuo9Q60VDCuHCFjuKgvkl o0BdajYuDHImvxuzbbWUvEqr7RpkAB0Nl9mTzhiWAUKpPKl3uP876ieYNMzdLE7aRa1a CFKq7uDBdGId5j0EF/G5jOlEZP6mjwhhxCZDY4DUSL5ZuTjXCQGBPs5FpScYw6AcrCjk 7MugG2ut9RLAzJ26fTDUweRtw4vDITnVWhXkasKlMoWwdqFTpkM+QynWn+Xw99t5lWcM xpCQ== X-Gm-Message-State: AIVw1125qBUD8C9/rLKMlzB/1jI2eyBWf2PdBAttHJCo81IsNov3eTY0 qbDuQnkRC+9qdQ== X-Received: by 10.107.131.9 with SMTP id f9mr6648713iod.225.1500007340585; Thu, 13 Jul 2017 21:42:20 -0700 (PDT) Original-Received: from lylat (S010664777d9cebe3.ss.shawcable.net. [70.64.85.59]) by smtp.gmail.com with ESMTPSA id a65sm4216734ioj.51.2017.07.13.21.42.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 13 Jul 2017 21:42:19 -0700 (PDT) In-Reply-To: <877ezbew3d.fsf@users.sourceforge.net> (npostavs's message of "Thu, 13 Jul 2017 19:49:26 -0400") 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:134527 Archived-At: npostavs@users.sourceforge.net writes: > Alex writes: > >> npostavs@users.sourceforge.net writes: >>> It would be nice if we can make code inside tests behave the same as >>> outside. But we should make it conditional on whether the code is being >>> compiled, otherwise code inside tests would behave differently when >>> being interpreted. Anyway, we can leave this for a separate bug. >> >> I agree, but that sounds like it'll require a fair bit of refactoring >> and knowledge of ert internals. > > I don't think so, just a conditional to decide whether or not to call > the extra expansion. Do you think there is anything else? I was mostly referring to not binding `debugger', but also evaluating the code "normally" (i.e., not doing expansions first in one condition-case, evaluating arguments in another, and then the whole form in a third one). >> OOC, is there a robust way to check whether or not you're currently >> byte-compiling? > > AFAIK, the usual trick is (bound-and-true-p byte-compile-current-file). > It's probably good enough for most things. I believe the below patch does that, though it has some issues. >> I was going to ask if you would merge in a few days, but it appears that >> what should have been a simple rebase to master caused unforeseen >> consequences. For instance, for some reason I now get a segmentation >> fault when executing 'make cl-lib-tests TEST_LOAD_EL=no'. I even reset >> to the commit I was at before and it still segfaults. Can you reproduce >> this with the following patch on master? > > Nope, I just get the failures on cl-lib-defstruct-record we already > mentioned. The segfault appears to have been because I didn't wipe out the elc files when testing different implementations. I spent a lot longer than I'd like to admit finding this out. Is there a reason why "make clean" in the test directory doesn't wipe out elc files? I don't understand why there's a separate bootstrap-clean that does this. Can this and TEST_LOAD_EL please be documented in the test README? Anyway, I got everything back in order. Sadly, there's a couple extra tests that now fail for me in the patch that *doesn't* expand inline functions, and these don't fail for me in a clean master. They are in eieio-tests (23 and 24). With the inline expansion, I also get some errors in ert-tests. All of the errors, with the exception of subr-tests error, seem to be from cl-defstruct and cl-typep (which is defined by define-inline). Do you have any ideas? There should be 5 unexpected errors without the inline expansion, and 6 errors with it. Note that all tests pass in both cases without "TEST_LOAD_EL=no". If it's easy to fix the eieio tests and not the other ones, then it might be better to leave the inline-function expansion out for now.