bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#42940: feature/native-comp; xref-find-definition searches compile lo


From: Tom Gillespie
Subject: bug#42940: feature/native-comp; xref-find-definition searches compile location of el files instead of install location
Date: Sat, 22 Aug 2020 16:46:54 -0700

Here is another test case.

emacs -q -batch --no-site-file --eval "(xref-find-definitions 'defun)"
No library 
/var/tmp/portage/app-editors/emacs-28.0.9999-r1/work/emacs/lisp/emacs-lisp/byte-run.el
in search path
No definitions found for: defun

emacs -q -batch --no-site-file --eval "(require 'byte-run)" --eval
"(xref-find-definitions 'defun)"
Loading file 
/usr/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/eln-cache/x86_64-pc-linux-gnu-bbae9d63d1309894/byte-run-1e5facaeb87321037982c815be905e28eaf4253c367238bb2eff9b4286620542.eln
failed to provide feature ‘byte-run’

On Sat, Aug 22, 2020 at 2:53 PM Tom Gillespie <tgbugs@gmail.com> wrote:
>
> It seems that the problem was only partially fixed at
> c818c29771d3cb51875643b2f6c894073e429dd2.
>
> emacs -q -batch --no-site-file --eval "(xref-find-definitions
> 'shell-command)" succeeds whereas
>
> emacs -q -batch --no-site-file --eval "(xref-find-definitions 'looking-at-p)"
> No library 
> /var/tmp/portage/app-editors/emacs-28.0.9999-r1/work/emacs/lisp/subr.el
> in search path
> No definitions found for: looking-at-p
>
> A wrinkle is that the following succeeds when I explicitly require
> 'subr, but produces another warning which seems like it
> might be related to why 'looking-at-p is not found without explicitly
> requiring 'subr.
> emacs -q -batch --no-site-file --eval "(require 'subr)" --eval
> "(xref-find-definitions 'looking-at-p)"
> Loading file 
> /usr/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/eln-cache/x86_64-pc-linux-gnu-bbae9d63d1309894/subr-8e7058db29bf20a68ef89651c940f16d2e5087b6bf685b48ddeb1de1dcd6ad02.eln
> failed to provide feature ‘subr’
>
> On Fri, Aug 21, 2020 at 12:44 AM Andrea Corallo <akrl@sdf.org> wrote:
> >
> > Tom Gillespie <tgbugs@gmail.com> writes:
> >
> > > This is fixed at c818c29771d3cb51875643b2f6c894073e429dd2 for me so it
> > > looks like that reversion did the trick. Thanks!
> >
> > Thank you for reporting that!  Closing
> >
> >   Andrea
> >
> > --
> > akrl@sdf.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]