From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: emacs-30 6bca138d60e: Fix latest test for dabbrev-expand Date: Tue, 03 Dec 2024 03:14:26 -0500 Message-ID: References: <173314163483.652988.2881826266893472321@vcs3.savannah.gnu.org> <20241202121355.3BF7D526A27@vcs3.savannah.gnu.org> <87plm9ybmc.fsf@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37142"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Stephen Berman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 03 09:15:18 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tIO3x-0009SJ-S1 for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Dec 2024 09:15:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tIO3C-0005A3-Tf; Tue, 03 Dec 2024 03:14:30 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tIO3B-00059f-2X for emacs-devel@gnu.org; Tue, 03 Dec 2024 03:14:29 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tIO39-00018W-Oo; Tue, 03 Dec 2024 03:14:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=NB7Un3iKXcS5bkoGxLJUawkI7Dionq1DoS817NamaK8=; b=LLqRfUCCQayMDMSUCYs8 FR0YpLavkGjTfGwE4Cl9pTpe5jTzX/cMXcFfDBLuj4mflPBhYzgAVfK4IEDW4yUsHnLUWj0EiqZQP WS9URvqjnVvQyGN3QVT50WkaMON0iikFi0aGYKvqGg5cemhUZu1tOy7OhlOO0Cf4V+Ijg0aa0pH5P YguW+Jf8DTi/cNC0ooVP/LGh7UU5wrkIInrNC/4844jQHCw4nq3Ac5QfuFkUzks+WoU+gIR41vxWF RWc4lFjEicFsjnZvWiSiFfEvko8oXkD8jTDRBeBWDtGQ81C33QzmpT+3rygEOkfwR095fTyGYpS0O F5StA+FkDj+98g==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1tIO38-0002Zf-U1; Tue, 03 Dec 2024 03:14:27 -0500 In-Reply-To: <87plm9ybmc.fsf@gmx.net> (Stephen Berman's message of "Mon, 02 Dec 2024 23:16:11 +0100") X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:325973 Archived-At: Stephen Berman writes: > On Mon, 02 Dec 2024 15:45:23 -0500 Andrea Corallo wrot= e: > >> Stephen Berman via Mailing list for Emacs changes >> writes: >> >>> branch: emacs-30 >>> commit 6bca138d60e47d0fbab4faf8e83c5b9b319f260d >>> Author: Stephen Berman >>> Commit: Stephen Berman >>> >>> Fix latest test for dabbrev-expand >>> >>> * test/lisp/dabbrev-tests.el (dabbrev-expand-after-killing-buffer): >>> Fix typo in a 'should' test, use part of return value of 'should-er= ror' >>> test, and remove mistaken and unfounded FIXME comment. >> >> Hello Stephen, >> >> this commit is introducing in my test-bed the following three failures >> in emacs-30: dabbrev-expand-test-other-buffer-4, >> dabbrev-expand-test-other-buffer-3, dabbrev-expand-after-killing-buffer. >> Could you please have a look? >> >> Andrea > > How does your testbed run the tests? When I invoke `emacs-30 -batch -l > ~/src/emacs/emacs-30/test/lisp/dabbrev-tests.el -f > ert-run-tests-batch-and-exit' from the shell, all tests pass. Likewise, > when I start emacs-30 -Q, then `M-x load-file > ~/src/emacs/emacs-30/test/lisp/dabbrev-tests.el', then kill all > non-hidden buffers except *scratch*, and then run `M-x ert', all tests > pass. Since the batch run is also used by `make check', I've assumed > that, since the tests succeed (at least for me) in this mode, they are > valid regression tests. > > In contrast, when I start emacs -Q, visit > ~/src/emacs/emacs-30/test/lisp/dabbrev-tests.el, evaluate the buffer and > run `M-x ert', then I get five test failures: > dabbrev-expand-test-other-buffer-{1,2,3,4} and > dabbrev-expand-after-killing-buffer. The latter fails because > dabbrev-expand finds an expansion in the test file buffer (but succeeds > when there is no such buffer, as in the previous run starting with -Q). > The four other tests fail possibly for the same reason; however, these > four tests fail in this way since being introduced in commit 8113b5c562 > (see > https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-10/msg01752.html), > so it puzzles me that you only see just two of those failures and only > after my latest commit. (However, I did get the same three failures you > reported when I ran ert on the test file from commit bd8a6f70fb, > i.e. the one prior to the above commit, but only after uncommenting the > code lines that are commented out in that commit. Could it be that you > accidentally tested using that previous commit with those code lines > uncommented?) > > Steve Berman Hi Steve, my testbench is running "make check -j24" on a fresh checkout on x86_64-pc-linux-gnu for few different configurations. For instance I can see the failures on the latest emacs-30 e618d5ae941d005e9da6d5d5cba68cc0ecade0e5 configured with "--with-native-compilation=3Dno --with-x-toolkit=3Dno". Test dabbrev-expand-test-other-buffer-3 backtrace: signal(ert-test-failed (((should (string=3D (buffer-string) "Indic and ert-fail(((should (string=3D (buffer-string) "Indic and")) :form (stri #f(compiled-function () #)() #f(compiled-function () #)() handler-bind-1(#f(compiled-function () #)() #f(compiled-function () #)() handler-bind-1(#f(compiled-function () #)() #f(compiled-function () #)() handler-bind-1(#f(compiled-function () #