Possible macro-expansion or pcase-related bug in Emacs 28 #232
Labels
Comments
|
I can't reproduce this. However, you might be encountering a very strange problem that I recently found happening only in the GitHub Actions CI tests (i.e. the tests always pass locally). I had to disable one test, because it didn't even fail in a comprehensible way--Buttercup didn't even give a useful failure message. I just pushed a temp branch with that test re-enabled, which shows the failures: https://github.com/alphapapa/org-ql/runs/2987486139 Please evaluate this form and tell me the result: (org-ql--normalize-query '(or (ts-active :on "2019-01-01")
(ts-a :on "2019-01-01")
(ts-inactive :on "2019-01-01")
(ts-i :on "2019-01-01")))Also:
Thanks. |
|
I get Symbol’s value as variable is void: rest. passing each clause one by one results in the same error. executing Line 1142 in 8342656 brings up warning that reads 1 I installed the package from MELPA. I also have tried the latest commit from git. I have ran the tests that came with the package. |
|
How did you install Emacs? From what source and/or package? When you installed versions of this package other than from MELPA, what procedure did you follow?
I don't understand what that means. |
|
I built emacs 28.0.5 from source on my machine.
I meant, my version of emacs is 28.0.5 and org-ql declares emacs 26.1. The packages I use are either the same version or higher compared to what is declared in org-ql. |
|
Thanks. Please note that Emacs 28 is not yet released, and by running Emacs master, you do open yourself up to occasional pre-release breakage (e.g. alphapapa/ts.el#18, though probably not related to this problem). As well, sometimes breaking changes happen from one Emacs release to another, so although this package requires at least Emacs 26.1, that doesn't mean that subsequent Emacs releases won't exhibit problems. And the same goes for package versions: using a version of a package later than the minimum declared version doesn't mean a problem won't arise. Anyway, I may have found the problem. Please test this commit: 85540f5 |
Please elaborate on this as well. Did you then install the built Emacs? Or did you run it from the build directory? Did you change any of the build options or flags? Can you reproduce this problem by using a distro-provided Emacs package? I ask these questions because I am completely unable to reproduce the problem on my system, and yet it also happens on GitHub CI, but not to the degree which you encounter it (i.e. only that one test fails, while for you, it seems like actually running searches fails). The only possible explanation I have at the moment is some difference in how Emacs is built or installed, a difference which may be common to your system and the Nix-based environment used in the CI. I have once encountered a similarly weird problem which was caused by a distro-provided package installing a system-level Elisp file that shadowed another one, causing obsolete/broken code to be invisibly loaded before my own config; it was a major pain to troubleshoot. That seems unlikely, but it's all I have left. |
|
The latest commit suffers from the same issue. I installed emacs 27.2-1 and org-ql works on it without issues. This is most likely issue related with emacs 28.5. |
|
As much as I'd like to close this issue and forget about it, I think that would be unwise, considering how a change in Emacs 28.0.50 was recently discovered to affect @tpeacock19 Since you recently and very rapidly (from my perspective!) tracked down a similar change in Emacs 28, would you be able to help here? If you can bisect it with a script, this Lisp form should signal an error only after the breaking change in Emacs 28: (org-ql--normalize-query '(or (ts-active :on "2019-01-01")
(ts-a :on "2019-01-01")
(ts-inactive :on "2019-01-01")
(ts-i :on "2019-01-01")))Although byte-compiling and/or loading the package's files may also warn or error about void/free variables after the breaking change (assuming there is one). Also, I can't be certain that this is exclusive to Emacs 28, because before 85540f5, that one test fails on 26.3, 27.1, and 27.2 also, but only on CI--not on my system. But none of the other tests fail, i.e. the ones that actually test the query results, which doesn't make sense, because they should exercise the same code paths. While messing with these variable names in the
Notably, the |
alphapapa
changed the title
|
As a side note, I am building emacs from the arch user repository. I was on emacs-version 28.50 |
Yes, it would be good to test with the latest version first. Regarding "Please avoid it" errors, I searched and found this discussion from 2016: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20784#35 That doesn't explain what's going on here, but Stefan did say:
I wonder if I have encountered one of those "corner cases...when doing metaprogramming"... |
|
I built and no issues. |
That's unrelated to this problem; see relevant issue/PR on this repo.
Okay, so to summarize:
Is that correct? |
|
|
Note to self: Issues with So that test failure appears to be unrelated to the void/free variable errors described here. The errors described here...I have no explanation for them, other than it being caused by a change in Emacs 28.0 that's already been fixed. @tpeacock19 Please ignore my request for your help, and sorry for the noise. So, unless this can ever be reproduced, it does not appear to be a bug in this package, or even in Emacs anymore. @natask When reporting bugs, please be careful to reproduce them on either the latest released Emacs version, and/or on the latest commit from Emacs master (in which case it might indicate a bug in Emacs rather than in this package). My first instinct in replying to this issue was to point to the passing tests and suggest a problem on your end, but then I remembered the apparently weird test failures I had recently, and I thought maybe they were related...so I went down the rabbit hole...and 2 hours later, it turns out to have been simply a case of your running an outdated master build of an unreleased Emacs version. :/ |
|
My sincere apologizes. I will do so in the future. |
|
Well, it's a lesson for me, too: in your first message, you said your Emacs build was "of 2020-08-20," and I noticed it, but I decided to start digging anyway. I should have waited for confirmation about the latest Emacs build before investing much time. At least this helped me verify the cause of that weird test failure, so maybe some good came from it. Thanks for your quick responses. |
|
Also, note to self: I think my causing the |
I'm getting this error, perhaps it's worth creating a new issue? Here are the details for now regardless: GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0) Using trivial org file: backtrace: |
|
@ParetoOptimalDev Please try to reproduce the problem in the latest release of Emacs. |
In the release emacs 29.3 version things work perfectly fine. I can just use 29.3 for now as a workaround. |
|
So how recent was the build from master that you found the problem on? |
I'm getting "please avoid it" error using commit 6b7ff60a5e71c161a064e27509fe4fb95cf74ddd, I'll go back to stable 29.3 for now. |
|
The most recent commit that touches the code where that message appears is: But the purpose of that commit is not to cause such an error to happen where one did not previously. So would you please confirm that the error happens on commit 806759dc0a6a3b049ce35d0497011464e5fc4dcb and does not happen on commit 9ebc91795f2? Also, please be sure to recompile the org-ql package on each Emacs commit before testing it. |
|
FWIW, I installed |
|
Here is my test result (for the "Please avoid it" error) :
here is my my test procedure
(require 'package)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)
(package-initialize)
(package-refresh-contents)
|
|
Well, that narrows it down to something between 806759dc0a6a3b049ce35d0497011464e5fc4dcb and 6b7ff60a5e71c161a064e27509fe4fb95cf74ddd, because that is the latest commit on emacs.git master and it has nothing to do with this issue. It's also curious that you could not reproduce it with 806759dc0a6a3b049ce35d0497011464e5fc4dcb, which is the change that last touched that code. Since you have the procedure lined up, you could Actually, AFAICT the problem commit must be after 170c6557922, because that is the one I could not reproduce the problem with. |
|
|
|
Great, thanks. @smonnier I remember that thread on the mailing list, and I'm happy for that change, but it looks like it may introduce a backward-incompatibility (either that, or expose a problem which was not the case before). What do you think? |
|
Posted at #433 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am getting (void-variable rest) whenever I try to use (scheduled :to today) and/or (ts-active :on today).
I traced it down to
org-ql/org-ql.el
Line 373 in 8342656
I believe the bug is caused by org-ql--normalize-from-to-on.
I am using the lastest commit 8342656
GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, cairo version 1.17.3) of 2020-08-20
The text was updated successfully, but these errors were encountered: