-
-
Notifications
You must be signed in to change notification settings - Fork 884
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Eager macro-expansion failure in lsp-terraform.el #3577
Comments
cc @psibi |
@condy0919 Thanks for the bug report! I tried using Is there any specific steps that I can follow to reproduce this issue ? Sharing your configuration might help me. |
Enabling byte-compile https://github.com/emacs-lsp/lsp-mode/blob/master/scripts/lsp-start-plain.el#L37= |
@condy0919 Thanks, I checked
|
Install clang or open an elisp file since |
Sure, I installed
I also opened an elisp file and I can't observe anything. I think it would be helpful if you can share your lsp-mode configuration that you are using. |
@condy0919 are you reproducing the issue with |
Yes, except for the nil no-byte-compile variable. |
I will then provide a minimal recipe init.el |
Sorry to disturb, I'm unable to reproduce after deleting all packages and reinstalling them again. :'( The reason I guess is the *.elc files is generated by Emacs master at commit1, but later they're run on Emacs 29 at commint2. |
Met the same issue today.
|
This shouldn't be necessary but 🤷 emacs-lsp#3577
I hit this issue today as well. I'm using emacs 29, and commit 0dfe214 of lsp-mode. The other workarounds posted above didn't seem to work for me, but I don't use terraform these days, so I just removed the client from the list: (delete 'lsp-terraform lsp-client-packages) Now all my lsp clients (excluding terraform, of course) seem to work normally. Another user has forked lsp-mode to add this commit for a seemingly more correct fix: SteVwonder@db55e4f Perhaps this issue should be reopened? |
I'm experiencing this as well since last week when opening a Go file.
|
Got same error as @shackra |
This appears to fix the error in [issue 3577](emacs-lsp#3577) for me: as I made these edits in my local straight copy of lsp-mode, I saw the error message (which was appearing when I called 'revert-buffer in a non-terraform buffer for which lsp-mode was configured) move from reporting ``` Error running timer: (error "Eager macro-expansion failure: (error \"Unknown key: :docs-link. Available keys: (:name :docs_link :version :source_type :dependent_modules)\")") ``` to ``` Error running timer: (error "Eager macro-expansion failure: (error \"Unknown key: :source-type. Available keys: (:name :docs_link :version :source_type :dependent_modules)\")") ``` and so on. Interestingly, flycheck is reporting the exact opposite message now, claiming that “:docs_link” is an unknown key and “:docs-link” should be available. Not sure what’s going on!
EDIT: I don’t think this actually works – I’m not sure why it appeared to fix my problem, but the problem later came back and my changes were the cause this time, with the problem fixed by removing my changes. Original comment: I’ve been having this for a while now, and have fixed my own setup by making what I think is the opposite edit to the one made by SteVWonder: emdash-ie@c05484d I’m using emacs 29 on macOS via doom emacs, so I don’t have a minimal reproduction, but I wanted to describe what worked for me in case it’s helpful in diagnosing the issue:
Sorry if this is unhelpful! The fact that it’s only started recently does make me think this is caused by something elsewhere, e.g. a byte-compilation issue, but I don’t know enough about that to be able to look into it properly. |
This is absolutely a problem that is impacting lots of users, as well as dozens of people in this thread alone. In one of the issues linked, @yyoncho claims a clean install fixes this, but for me this failure arose in a brand-new from-scratch Doom installation, so unless I'm not understanding what "clean install" means, I don't think this is true. The only robust solution for Doom uses seems to be to use a forked version of lsp-mode with a patch like @emdash-ie posted above, which is really not ideal. I understand that this may be hard to definitively repro, but this breaks lots of people, and given that the proposed patches work, it's unfortunate that this issue is not being addressed. |
I have seen others cleaning it up like this which made it work:
IIUC, the proposed patch will break the functionality for terraform-ls users. |
I started seeing this issue with Go files today with Doom on Emacs 29. I tried many things including purging elc files, reinstalling all modules, deleting lsp-mode repo from cache, etc. Nothing helped. As I'm not using Terraform, I followed @mattsawyer77's suggestion and I was able to get everything working back again. I added the following section to (after! lsp-mode
;; https://github.com/emacs-lsp/lsp-mode/issues/3577#issuecomment-1709232622
(delete 'lsp-terraform lsp-client-packages)) |
The answer from @kprav33n is working as expected but I do I tried deleting all |
Doom user here, and Go mode is quite broken for me in Emacs 29. Reverting to Emacs 28 fixes the problem. |
Came across the same issue today in Doom Emacs. I don't use terraform, so @kprav33n's solution works for me, but this issue really needs a real fix as staying on an old version of Emacs and removing functionality from the mode are not good long-term solutions. |
I cannot think of a reason for that to happen. Is there anyone actually managing to reproduce it with M-x lsp-start-plain? FWIW We can rewrite the code in lsp-terraform.el to use lsp-get instead of using destructoring. |
If someone wants to send a patch using I don't use doom emacs, so probably I could be mis-understanding how things work there - but from a quick look it looks like they are pinning commits: https://github.com/doomemacs/doomemacs/blob/03d692f129633e3bf0bd100d91b3ebf3f77db6d1/modules/tools/lsp/packages.el#L12C28-L12C68 which seem to use lsp-mode from Nov 2023 which is quite old and may have this bug: d441f3d |
This change seems to fix the problem for me. It looks like there was a typo in the name of the variable where a |
@JacobJanzen Is that bug reproducible to you when you do lsp-start-plain ?
My guess is if someone is using older version of doom emacs which ships a older lsp-mode.
Unfortunately that fix will break terraform-ls functionality since we won't be passing the parameters as expected by the terraform-ls server. |
@psibi The error does not seem to appear in the compile log with lsp-start-plain. |
My setup now works without error with my changes removed – lsp-mode is pinned to d441f3d and unmodified, and I can’t reproduce the error at all. (This also seems to have happened on a few other issues describing this problem.) Given this, I think @yyoncho and @psibi are correct that there is no bug in lsp-mode, and that the problem is about some odd byte-compilation clash. (Maybe running |
This was premature: I don’t understand why it appeared to be fixed, but I still get this error. My current fix (which sometimes only lasts until I restart emacs, and sometimes confusingly lasts longer) is to evaluate these three lines using |
This worked for me too - same issue as others here; LSP not working (only for go, strangely? Python is fine). |
This suddenly started happening for me too - all I did was update my OS packages (Ubuntu 20.04), nothing changed AFAIK in my Emacs config or packages. I tried updating all my packages including lsp in case it helped, then fully reloaded all my elpa packages from scratch, but nothing helped. Since I don't use terraform, SteVwonder@db55e4f seemed to work for me. |
This is happening to me as well, very infuriating, same symptoms, and the fix above doesn't actually to be solving the problem unfortunately. Since I'm using doom emacs, I went ahead and just started trying out eglot, seems like the issue is solved. |
|
I also ran into this issue with Doom Emacs, specifically when opening a go file. Since I also use Terraform regularly I didn't want to disable it if I didn't have to. I ended up diving into my emacs config directory and brute-forced changes until the lsp server started successfully in my golang buffer. I don't know how sustainable this is, but I've been using it for the majority of day and haven't run into any issues. I'm almost certain this won't survive a doom package upgrade, so unless there's a more permanent solution I'm just going to keep running with this temp fix 😆 On my machine, lsp-mode is cloned to diff --git clients/lsp-terraform.el clients/lsp-terraform.el
index 686a5da61..b9bbbb3c7 100644
--- clients/lsp-terraform.el
+++ clients/lsp-terraform.el
@@ -302,7 +302,7 @@ This is a synchronous action."
:installed-version installed-version
:version-constraint (lsp-get provider :version_constraint)))
-(lsp-defun construct-tf-module ((&terraform-ls:Module :name :docs-link :version :source-type :dependent-modules))
+(lsp-defun construct-tf-module ((&terraform-ls:Module :name :docs_link :version :source_type :dependent_modules))
"Construct `TF-MODULE' using MODULE."
(make-tf-module :name name
:doc-link docs-link
@@ -310,7 +310,7 @@ This is a synchronous action."
:source-type source-type
:dependent-modules dependent-modules))
-(lsp-defun lsp-terraform-ls--providers-to-tf-package ((&terraform-ls:Providers :provider-requirements :installed-providers))
+(lsp-defun lsp-terraform-ls--providers-to-tf-package ((&terraform-ls:Providers :provider_requirements :installed_providers))
"Convert PROVIDERS-TREE-DATA to list of `tf-package'."
(let* ((provider-requirements-keys (hash-table-keys provider-requirements))
(installed-versions (mapcar (lambda (x) (lsp-get installed-providers (make-symbol (format ":%s" x)))) provider-requirements-keys))
@@ -318,7 +318,7 @@ This is a synchronous action."
(tf-packages (-zip-with (lambda (x y) (construct-tf-package x y)) providers installed-versions)))
tf-packages))
-(lsp-defun lsp-terraform-ls--modules-to-tf-module ((&terraform-ls:ModuleCalls :module-calls))
+(lsp-defun lsp-terraform-ls--modules-to-tf-module ((&terraform-ls:ModuleCalls :module_calls))
"Convert MODULES-TREE-DATA to list of `TF-MODULE'."
(let* ((modules (-map (lambda (x) (construct-tf-module x)) module-calls)))
modules)) |
Another Doom user here. I don't know why, but if I put (for non-Doom users, the effect of loading it like that in |
This issue seems to come up a lot, and I've been unable to reproduce it, but at the very least I can disable the lsp-terraform client for folks that don't need it. Fix: #7713 Ref: emacs-lsp/lsp-mode#3577
This issue seems to come up a lot, and I've been unable to reproduce it, but at the very least I can disable the lsp-terraform client for folks that don't need it. Fix: doomemacs#7713 Ref: emacs-lsp/lsp-mode#3577
Thank you for the bug report
lsp-mode
related packages.M-x lsp-start-plain
Bug description
According to lsp-protocol.el, the lsp interface of terraform should be:
But three macro-expansion failures happened.
Module
Providers
ModuleCalls
Steps to reproduce
Nothing
Expected behavior
No failures
Which Language Server did you use?
Nothing
OS
Linux
Error callstack
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: