GNU bug report logs - #43004
28.0.50; Test failures due to symlinked Emacs sources

Previous Next

To reply to this bug, email your comments to 43004 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Test failures due to symlinked Emacs sources
Date: Sun, 23 Aug 2020 23:27:03 +0200

After my latest build from master I ran make check (for the first time
in a long time) and got the following 20 unexpected failures:

In test/lisp/progmodes/elisp-mode-tests.el 14 unexpected results:
   FAILED  xref-elisp-test-find-defs-defgeneric-co-located-default
   FAILED  xref-elisp-test-find-defs-defgeneric-el
   FAILED  xref-elisp-test-find-defs-defgeneric-implicit-generic
   FAILED  xref-elisp-test-find-defs-defgeneric-no-default
   FAILED  xref-elisp-test-find-defs-defgeneric-no-methods
   FAILED  xref-elisp-test-find-defs-defgeneric-separate-default
   FAILED  xref-elisp-test-find-defs-define-overload-co-located-default
   FAILED  xref-elisp-test-find-defs-define-overload-no-default
   FAILED  xref-elisp-test-find-defs-define-overload-no-methods
   FAILED  xref-elisp-test-find-defs-define-overload-separate-default
   FAILED  xref-elisp-test-find-defs-defun-defvar-el
   FAILED  xref-elisp-test-find-defs-defun-el
   FAILED  xref-elisp-test-find-defs-defvar-el
   FAILED  xref-elisp-test-find-defs-feature-el

In test/lisp/help-fns-tests.el 5 unexpected results:
   FAILED  help-fns-test-alias-to-defun
   FAILED  help-fns-test-bug23887
   FAILED  help-fns-test-lisp-defsubst
   FAILED  help-fns-test-lisp-defun
   FAILED  help-fns-test-lisp-macro

In test/lisp/emacs-lisp/cl-generic-tests.el 1 unexpected result:
   FAILED  cl-generic-tests--method-files--finds-methods

It seems that the failures arise because my Emacs sources are in a
directory on a different partition from my home directory, and the
source directory is symlinked from §HOME, and my Emacs build directory
is under $HOME.  When I do batch runs of the test three files in
question starting from my home directory (i.e. dereferencing the symlink
to the sources), I get the the failures I reported; but when I start the
batch runs from the real directory containing the test sources, the one
test in cl-generic-tests.el that failed now passes, and of the fourteen
xref tests in elisp-mode-tests.el that failed, now only these five fail:

   FAILED  xref-elisp-test-find-defs-defgeneric-el
   FAILED  xref-elisp-test-find-defs-defun-defvar-el
   FAILED  xref-elisp-test-find-defs-defun-el
   FAILED  xref-elisp-test-find-defs-defvar-el
   FAILED  xref-elisp-test-find-defs-feature-el

But all five of the failing tests in help-fns-tests.el still fail.

However, concerning the latter, it seems that the tests expect
help-fns-function-description-header to return the quoted basename of
the file, while in my environment it returns the absolute filename.
Adjusting the regexp used in the tests fixes this issue (see the first
patch below) and then all tests pass regardless of where I start the
batch run.

Concerning cl-generic-tests.el, using file-truename as in the second
patch below prevents the one failure, also regardless of where I start
the batch run.

As for the failing xref tests in elisp-mode-tests.el, by applying
file-truename to the result of calls to find-lisp-object-file-name in
elisp--xref-find-definitions (in elisp-mode.el) and
xref-mode-local-overload (in mode-local.el) I could reduce the 14
failures to the same five that fail when doing the batch run from the
real directory without following the symlink.  The same reduction but
not full elimination is achieved by removing the call to file-truename
in the value of the defvar emacs-test-dir in elisp-mode-tests.el.  So
far I haven't figured out how to prevent these five failures.


diff --git a/test/lisp/help-fns-tests.el b/test/lisp/help-fns-tests.el
index da2b49e6b8..7782a41b9f 100644
--- a/test/lisp/help-fns-tests.el
+++ b/test/lisp/help-fns-tests.el
@@ -56,28 +56,28 @@ help-fns-test-interactive-built-in
     (should (string-match regexp result))))
 
 (ert-deftest help-fns-test-lisp-macro ()
-  (let ((regexp "a Lisp macro in .subr\\.el")
+  (let ((regexp "a Lisp macro in .+subr\\.el")
         (result (help-fns-tests--describe-function 'when)))
     (should (string-match regexp result))))
 
 (ert-deftest help-fns-test-lisp-defun ()
-  (let ((regexp "a compiled Lisp function in .subr\\.el")
+  (let ((regexp "a compiled Lisp function in .+subr\\.el")
         (result (help-fns-tests--describe-function 'last)))
     (should (string-match regexp result))))
 
 (ert-deftest help-fns-test-lisp-defsubst ()
-  (let ((regexp "a compiled Lisp function in .subr\\.el")
+  (let ((regexp "a compiled Lisp function in .+subr\\.el")
         (result (help-fns-tests--describe-function 'posn-window)))
     (should (string-match regexp result))))
 
 (ert-deftest help-fns-test-alias-to-defun ()
-  (let ((regexp "an alias for .set-file-modes. in .subr\\.el")
+  (let ((regexp "an alias for .set-file-modes. in .+subr\\.el")
         (result (help-fns-tests--describe-function 'chmod)))
     (should (string-match regexp result))))
 
 (ert-deftest help-fns-test-bug23887 ()
   "Test for https://debbugs.gnu.org/23887 ."
-  (let ((regexp "an alias for .re-search-forward. in .subr\\.el")
+  (let ((regexp "an alias for .re-search-forward. in .+subr\\.el")
         (result (help-fns-tests--describe-function 'search-forward-regexp)))
     (should (string-match regexp result))))
 

diff --git a/test/lisp/emacs-lisp/cl-generic-tests.el b/test/lisp/emacs-lisp/cl-generic-tests.el
index 5aa58782f3..9582907e51 100644
--- a/test/lisp/emacs-lisp/cl-generic-tests.el
+++ b/test/lisp/emacs-lisp/cl-generic-tests.el
@@ -240,7 +240,7 @@ cl-generic-tests--method-files--finds-methods
   (let ((retval (cl--generic-method-files 'cl-generic-tests--generic)))
     (should (equal (length retval) 2))
     (mapc (lambda (x)
-            (should (equal (car x) cl-generic-tests--this-file))
+            (should (equal (file-truename (car x)) cl-generic-tests--this-file))
             (should (equal (cadr x) 'cl-generic-tests--generic)))
           retval)
     (should-not (equal (nth 0 retval) (nth 1 retval)))))


In GNU Emacs 28.0.50 (build 16, x86_64-pc-linux-gnu, GTK+ Version 3.24.17, cairo version 1.17.3)
 of 2020-08-21 built on strobe-jhalfs
Repository revision: 3e10174fb65f4eb601b1921271bdcf10c933b879
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Linux From Scratch SVN-20200401

Configured using:
 'configure 'CFLAGS=-Og -g3' PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD PDUMPER LCMS2

Message #8 received at 43004 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 43004 <at> debbugs.gnu.org
Subject: Re: bug#43004: 28.0.50; Test failures due to symlinked Emacs sources
Date: Fri, 16 Oct 2020 10:34:30 +0200

Stephen Berman <stephen.berman <at> gmx.net> writes:

> However, concerning the latter, it seems that the tests expect
> help-fns-function-description-header to return the quoted basename of
> the file, while in my environment it returns the absolute filename.
> Adjusting the regexp used in the tests fixes this issue (see the first
> patch below) and then all tests pass regardless of where I start the
> batch run.
>
> Concerning cl-generic-tests.el, using file-truename as in the second
> patch below prevents the one failure, also regardless of where I start
> the batch run.

Thanks; I've now applied your patch to the trunk.

> The same reduction but not full elimination is achieved by removing
> the call to file-truename in the value of the defvar emacs-test-dir in
> elisp-mode-tests.el.  So far I haven't figured out how to prevent
> these five failures.

Have you made any progress on these remaining failures, by any chance?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 43004 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43004 <at> debbugs.gnu.org
Subject: Re: bug#43004: 28.0.50; Test failures due to symlinked Emacs sources
Date: Fri, 16 Oct 2020 16:15:43 +0200

[Message part 1 (text/plain, inline)]

On Fri, 16 Oct 2020 10:34:30 +0200 Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> However, concerning the latter, it seems that the tests expect
>> help-fns-function-description-header to return the quoted basename of
>> the file, while in my environment it returns the absolute filename.
>> Adjusting the regexp used in the tests fixes this issue (see the first
>> patch below) and then all tests pass regardless of where I start the
>> batch run.
>>
>> Concerning cl-generic-tests.el, using file-truename as in the second
>> patch below prevents the one failure, also regardless of where I start
>> the batch run.
>
> Thanks; I've now applied your patch to the trunk.

Thanks.

>> The same reduction but not full elimination is achieved by removing
>> the call to file-truename in the value of the defvar emacs-test-dir in
>> elisp-mode-tests.el.  So far I haven't figured out how to prevent
>> these five failures.
>
> Have you made any progress on these remaining failures, by any chance?

I looked at them again and, by trial and error, came up with the
attached patch, with which I now get no unexpected failures when running
the tests in batch mode, though when run interactively
xref-elisp-test-find-defs-defgeneric-implicit-generic still fails.  But
in any case I wouldn't blindly install this patch; someone who knows the
xref code really needs to look at what's going on here.

Steve Berman

[Message part 2 (text/x-patch, inline)]

diff --git a/test/lisp/progmodes/elisp-mode-tests.el b/test/lisp/progmodes/elisp-mode-tests.el
index 6c30e4f664..95259290ce 100644
--- a/test/lisp/progmodes/elisp-mode-tests.el
+++ b/test/lisp/progmodes/elisp-mode-tests.el
@@ -360,8 +360,7 @@ xref-elisp-deftest
 ;; `xref-elisp-test-run'.
 (defvar emacs-test-dir
   (funcall (if xref--case-insensitive 'downcase 'identity)
-           (file-truename (file-name-directory
-                           (or load-file-name (buffer-file-name))))))
+           (file-name-directory (or load-file-name (buffer-file-name)))))


 ;; alphabetical by test name
@@ -381,7 +380,8 @@ find-defs-constructor
     (xref-make "(cl-defstruct (xref-elisp-location (:constructor xref-make-elisp-location)))"
                (xref-make-elisp-location
                 'xref-elisp-location 'define-type
-                (expand-file-name "../../../lisp/progmodes/elisp-mode.el" emacs-test-dir)))
+                (file-truename
+                 (expand-file-name "../../../lisp/progmodes/elisp-mode.el" emacs-test-dir))))
     ;; It's not worth adding another special case to `xref-elisp-test-descr-to-target' for this
     "(cl-defstruct (xref-elisp-location")
    ))
@@ -392,11 +392,13 @@ find-defs-defalias-defun-el
    (xref-make "(defalias Buffer-menu-sort)"
 	      (xref-make-elisp-location
 	       'Buffer-menu-sort 'defalias
-	       (expand-file-name "../../../lisp/buff-menu.elc" emacs-test-dir)))
+	       (file-truename
+                 (expand-file-name "../../../lisp/buff-menu.elc" emacs-test-dir))))
    (xref-make "(defun tabulated-list-sort)"
 	      (xref-make-elisp-location
 	       'tabulated-list-sort nil
-	       (expand-file-name "../../../lisp/emacs-lisp/tabulated-list.el" emacs-test-dir)))
+	       (file-truename
+                 (expand-file-name "../../../lisp/emacs-lisp/tabulated-list.el" emacs-test-dir))))
    ))

 ;; FIXME: defconst
@@ -564,7 +566,8 @@ find-defs-defgeneric-el
 	       (cl--generic-load-hist-format
                 'xref-location-marker nil '(xref-elisp-location))
                'cl-defmethod
-	       (expand-file-name "../../../lisp/progmodes/elisp-mode.el" emacs-test-dir)))
+               (file-truename
+	        (expand-file-name "../../../lisp/progmodes/elisp-mode.el" emacs-test-dir))))
    (xref-make "(cl-defmethod xref-location-marker ((l xref-file-location)))"
 	      (xref-make-elisp-location
 	       (cl--generic-load-hist-format
@@ -724,7 +727,8 @@ find-defs-defun-el-defvar-c
     (xref-make "(defun abbrev-mode)"
                (xref-make-elisp-location
                 'abbrev-mode nil
-                (expand-file-name "../../../lisp/abbrev.el" emacs-test-dir)))
+                (file-truename
+                 (expand-file-name "../../../lisp/abbrev.el" emacs-test-dir))))
     "(define-minor-mode abbrev-mode"))
   )

@@ -778,11 +782,13 @@ find-defs-face-el
    (xref-make "(defvar font-lock-keyword-face)"
 	      (xref-make-elisp-location
 	       'font-lock-keyword-face 'defvar
-	       (expand-file-name "../../../lisp/font-lock.el" emacs-test-dir)))
+	       (file-truename
+                 (expand-file-name "../../../lisp/font-lock.el" emacs-test-dir))))
    (xref-make "(defface font-lock-keyword-face)"
 	      (xref-make-elisp-location
 	       'font-lock-keyword-face 'defface
-	       (expand-file-name "../../../lisp/font-lock.el" emacs-test-dir)))
+	       (file-truename
+                 (expand-file-name "../../../lisp/font-lock.el" emacs-test-dir))))
    ))

 (xref-elisp-deftest find-defs-face-eval

Message #14 received at 43004 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 43004 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#43004: 28.0.50; Test failures due to symlinked Emacs sources
Date: Fri, 16 Oct 2020 16:37:46 +0200

> I looked at them again and, by trial and error, came up with the
> attached patch, with which I now get no unexpected failures when running
> the tests in batch mode, though when run interactively
> xref-elisp-test-find-defs-defgeneric-implicit-generic still fails.  But
> in any case I wouldn't blindly install this patch; someone who knows the
> xref code really needs to look at what's going on here.

Dmitry, could you have a look at this patch to the xref tests?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #17 received at 43004 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43004 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#43004: 28.0.50; Test failures due to symlinked Emacs sources
Date: Fri, 16 Oct 2020 16:48:38 +0200

On Fri, 16 Oct 2020 16:37:46 +0200 Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

>> I looked at them again and, by trial and error, came up with the
>> attached patch, with which I now get no unexpected failures when running
>> the tests in batch mode, though when run interactively
>> xref-elisp-test-find-defs-defgeneric-implicit-generic still fails.  But
>> in any case I wouldn't blindly install this patch; someone who knows the
>> xref code really needs to look at what's going on here.
>
> Dmitry, could you have a look at this patch to the xref tests?

Yes, please.  I also just realized that I had run the patched batch mode
tests from my home directory, i.e., following the symlink.  When I run
them from the source directory without following the symlink, I get the
same five failures again (i.e., with the patch) that I had gotten before
without the patch.  So much for that attempt.

Steve Berman

Message #20 received at 43004 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stephen Berman <stephen.berman <at> gmx.net>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43004 <at> debbugs.gnu.org
Subject: Re: bug#43004: 28.0.50; Test failures due to symlinked Emacs sources
Date: Fri, 16 Oct 2020 23:20:19 +0300

On 16.10.2020 17:48, Stephen Berman wrote:
> Yes, please.  I also just realized that I had run the patched batch mode
> tests from my home directory, i.e., following the symlink.  When I run
> them from the source directory without following the symlink, I get the
> same five failures again (i.e., with the patch) that I had gotten before
> without the patch.  So much for that attempt.

So... the patch doesn't work?

I'm not sure what would be the best change here, or whether your usage 
is something we absolutely need to support in 'make check' (Lars? do 
we?), but one thing that should help is the exact examples of strings ( 
absolute file names) that mismatch.

Message #23 received at 43004 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 43004 <at> debbugs.gnu.org
Subject: Re: bug#43004: 28.0.50; Test failures due to symlinked Emacs sources
Date: Fri, 16 Oct 2020 22:54:21 +0200

[Message part 1 (text/plain, inline)]

On Fri, 16 Oct 2020 23:20:19 +0300 Dmitry Gutov <dgutov <at> yandex.ru> wrote:

> On 16.10.2020 17:48, Stephen Berman wrote:
>> Yes, please.  I also just realized that I had run the patched batch mode
>> tests from my home directory, i.e., following the symlink.  When I run
>> them from the source directory without following the symlink, I get the
>> same five failures again (i.e., with the patch) that I had gotten before
>> without the patch.  So much for that attempt.
>
> So... the patch doesn't work?
>
> I'm not sure what would be the best change here, or whether your usage is
> something we absolutely need to support in 'make check' (Lars? do we?), but
> one thing that should help is the exact examples of strings ( absolute file
> names) that mismatch.

I've attached the output of two batch runs using the patched
elisp-mode-tests.el.  The first run was executed from my home directory,
the second run was executed from the partition the file is really
located on, which is symlinked from my home directory:

(expand-file-name
"~/src/emacs/emacs-master/test/lisp/progmodes/elisp-mode-tests.el")
=>
"/home/steve/src/emacs/emacs-master/test/lisp/progmodes/elisp-mode-tests.el"

(file-truename
"/home/steve/src/emacs/emacs-master/test/lisp/progmodes/elisp-mode-tests.el")
=>
"/datadisk/steve/src/emacs/emacs-master/test/lisp/progmodes/elisp-mode-tests.el"

On the first run there are no unexpected failures, on the second, there
are five unexpected failures.

Steve Berman

[xref-tests (text/plain, attachment)]

Message #26 received at 43004 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 43004 <at> debbugs.gnu.org
Subject: Re: bug#43004: 28.0.50; Test failures due to symlinked Emacs sources
Date: Sat, 17 Oct 2020 08:39:38 +0200

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> I'm not sure what would be the best change here, or whether your usage
> is something we absolutely need to support in 'make check' (Lars? do
> we?), but one thing that should help is the exact examples of strings
> ( absolute file names) that mismatch.

It'd certainly be nice if this worked -- especially since these are the
only checks that fail in this situation.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #29 received at 43004 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Glenn Morris <rgm <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 43004 <at> debbugs.gnu.org
Subject: Re: bug#43004: 28.0.50; Test failures due to symlinked Emacs sources
Date: Fri, 30 Oct 2020 01:02:14 +0200

On 16.10.2020 23:54, Stephen Berman wrote:
> I've attached the output of two batch runs using the patched
> elisp-mode-tests.el.  The first run was executed from my home directory,
> the second run was executed from the partition the file is really
> located on, which is symlinked from my home directory:
> 
> (expand-file-name
> "~/src/emacs/emacs-master/test/lisp/progmodes/elisp-mode-tests.el")
> =>
> "/home/steve/src/emacs/emacs-master/test/lisp/progmodes/elisp-mode-tests.el"
> 
> (file-truename
> "/home/steve/src/emacs/emacs-master/test/lisp/progmodes/elisp-mode-tests.el")
> =>
> "/datadisk/steve/src/emacs/emacs-master/test/lisp/progmodes/elisp-mode-tests.el"
> 
> On the first run there are no unexpected failures, on the second, there
> are five unexpected failures.

So, what happens if you just remove the 'file-truename' call from the 
declaration of emacs-test-dir?

It was added by Glenn in c4ecc01a45, and there must be a reason for it, 
but it seems like it causes the current failures.

Ultimately, if we don't manage to fix it in an easy way, we could 
replace the

  (should (equal xref expected-xref))

comparison inside xref-elisp-test-run with multiple deeper comparisons 
(and use file-equal-p instead of equal for file names). Or call 
xref-location-marker and compare markers.

Message #32 received at 43004 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Glenn Morris <rgm <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 43004 <at> debbugs.gnu.org
Subject: Re: bug#43004: 28.0.50; Test failures due to symlinked Emacs sources
Date: Fri, 30 Oct 2020 22:26:21 +0100

On Fri, 30 Oct 2020 01:02:14 +0200 Dmitry Gutov <dgutov <at> yandex.ru> wrote:

> On 16.10.2020 23:54, Stephen Berman wrote:
>> I've attached the output of two batch runs using the patched
>> elisp-mode-tests.el.  The first run was executed from my home directory,
>> the second run was executed from the partition the file is really
>> located on, which is symlinked from my home directory:
>> (expand-file-name
>> "~/src/emacs/emacs-master/test/lisp/progmodes/elisp-mode-tests.el")
>> =>
>> "/home/steve/src/emacs/emacs-master/test/lisp/progmodes/elisp-mode-tests.el"
>> (file-truename
>> "/home/steve/src/emacs/emacs-master/test/lisp/progmodes/elisp-mode-tests.el")
>> =>
>> "/datadisk/steve/src/emacs/emacs-master/test/lisp/progmodes/elisp-mode-tests.el"
>> On the first run there are no unexpected failures, on the second, there
>> are five unexpected failures.
>
> So, what happens if you just remove the 'file-truename' call from the
> declaration of emacs-test-dir?

That's what I did in my patch in <87r1pyz27k.fsf <at> gmx.net>
(https://debbugs.gnu.org/cgi/bugreport.cgi?msg=11;att=1;bug=43004) and
initially concluded that with that patch "I now get no unexpected
failures when running the tests in batch mode, though when run
interactively xref-elisp-test-find-defs-defgeneric-implicit-generic
still fails."  But then in my next followup: "I also just realized that
I had run the patched batch mode tests from my home directory, i.e.,
following the symlink.  When I run them from the source directory
without following the symlink, I get the same five failures again (i.e.,
with the patch) that I had gotten before without the patch.  So much for
that attempt."

> It was added by Glenn in c4ecc01a45, and there must be a reason for it, but it
> seems like it causes the current failures.
>
> Ultimately, if we don't manage to fix it in an easy way, we could replace the
>
>   (should (equal xref expected-xref))
>
> comparison inside xref-elisp-test-run with multiple deeper comparisons (and
> use file-equal-p instead of equal for file names). Or call
> xref-location-marker and compare markers.

That may be a better test for my setup.

Steve Berman

Message #35 received at 43004 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Glenn Morris <rgm <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 43004 <at> debbugs.gnu.org
Subject: Re: bug#43004: 28.0.50; Test failures due to symlinked Emacs sources
Date: Sat, 31 Oct 2020 03:39:12 +0200

On 30.10.2020 23:26, Stephen Berman wrote:
> That's what I did in my patch in<87r1pyz27k.fsf <at> gmx.net>
> (https://debbugs.gnu.org/cgi/bugreport.cgi?msg=11;att=1;bug=43004) and
> initially concluded that with that patch "I now get no unexpected
> failures when running the tests in batch mode, though when run
> interactively xref-elisp-test-find-defs-defgeneric-implicit-generic
> still fails."

But looking at that patch, you moved some of the 'file-truename' calls, 
at least, down inside the test definitions, to produce the "expected" 
values.

What happens if you just remove that 'file-truename' call without adding 
it somewhere else?

Message #38 received at 43004 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Glenn Morris <rgm <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 43004 <at> debbugs.gnu.org
Subject: Re: bug#43004: 28.0.50; Test failures due to symlinked Emacs sources
Date: Sat, 31 Oct 2020 22:30:48 +0100

[Message part 1 (text/plain, inline)]

On Sat, 31 Oct 2020 03:39:12 +0200 Dmitry Gutov <dgutov <at> yandex.ru> wrote:

> On 30.10.2020 23:26, Stephen Berman wrote:
>> That's what I did in my patch in<87r1pyz27k.fsf <at> gmx.net>
>> (https://debbugs.gnu.org/cgi/bugreport.cgi?msg=11;att=1;bug=43004) and
>> initially concluded that with that patch "I now get no unexpected
>> failures when running the tests in batch mode, though when run
>> interactively xref-elisp-test-find-defs-defgeneric-implicit-generic
>> still fails."
>
> But looking at that patch, you moved some of the 'file-truename' calls, at
> least, down inside the test definitions, to produce the "expected" values.
>
> What happens if you just remove that 'file-truename' call without adding it
> somewhere else?

With just that change, a batch run started in the test subdirectory of
the emacs sources symlinked from my home directory gives:

5 unexpected results:
   FAILED  xref-elisp-test-find-defs-constructor
   FAILED  xref-elisp-test-find-defs-defalias-defun-el
   FAILED  xref-elisp-test-find-defs-defgeneric-el
   FAILED  xref-elisp-test-find-defs-defun-el-defvar-c
   FAILED  xref-elisp-test-find-defs-face-el

A batch run started in the non-symlinked test subdirectory gives:

5 unexpected results:
   FAILED  xref-elisp-test-find-defs-defgeneric-el
   FAILED  xref-elisp-test-find-defs-defun-defvar-el
   FAILED  xref-elisp-test-find-defs-defun-el
   FAILED  xref-elisp-test-find-defs-defvar-el
   FAILED  xref-elisp-test-find-defs-feature-el

Full output of the batch runs is attached.

Steve Berman

[Message part 2 (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.