latest version will cause emacs/rustic with eglot cpu 100% forever when open core library

[zylthinking]

I can't reproduce this on other project, including std. But when I open the core library by goto defination on a type, it happens 100%

It is emacs process eating CPU, but with older RA, this never happens. So, I don't know whether is an emacs bug or RA returned something to emacs causing it busy for ever

The library is the one shipped with stable 1.81.

[roife]

It works fine on my Emacs with rust-mode and the latest version of rust-analyzer.🤔

It is emacs process eating CPU, but with older RA, this never happens.

Are you using eglot or lsp-mode?

[zylthinking]

Are you using eglot or lsp-mode?

I am using eglot with rustic-mode

The RA cimmit id is 779d9eee2ea403da447278a7007c9627c8878856 (tag: 2024-09-02) Now I rollbacked to c9109f23de57359df39db6fa36b5ca4c64b671e1 (HEAD, tag: 2024-08-05) and everything became OK.

It works fine on my Emacs with rust-mode and the latest version of rust-analyzer.🤔

Because project/projectile only index directories containing .git by default, I configed it to index when there is a Cargo.toml too. So, maybe because RA does not index the core library so it seems working fine.

[zylthinking]

commit bd6fb363f07 has this issue, 9a090a28702177 has not (authough it report some overly long loop took ... etc which I never met before c9109f2)

So I believe the cpu consuming modification is from 30d5c86538

*   commit bd6fb363f072b7a48ac624ee46791187f0a0bbd4
|\  Merge: 30d5c86538 9a090a2870
| | Author: Laurențiu Nicola <[email protected]>
| | Date:   Tue Aug 13 17:58:52 2024 +0300
| | 
| |     Merge from rust-lang/rust
| |   
| *   commit 9a090a287021772453450d580878de959cd82b8d (HEAD)
| |\  Merge: 95f691a4c5 199ce2e326
| | | Author: bors <[email protected]>

[zylthinking]

Trying rust-mode without any other changes, no problems occurs. It should be some weakness of rustic-mode

[zylthinking]

a.zip Sorry, the issue is still there. With eglot & rust-mode I saw tons of rust-analyzer reporting of error in eglot logs which is why the cpu is so high, a piece of which is shown below, full output is attached:

       (:range
                  (:start
                   (:line 97 :character 8)
                   :end
                   (:line 97 :character 45))
                  :severity 4 :code "E0034" :codeDescription
                  (:href "https://doc.rust-lang.org/error-index.html#E0034")
                  :source "rustc" :message "candidate #2 is defined in an impl for the type `i64`" :relatedInformation
                  [(:location
                    (:uri "file:///home/zylthinking/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/saturating.rs" :range
                          (:start
                           (:line 853 :character 0)
                           :end
                           (:line 853 :character 76)))
                    :message "original diagnostic")])
                 (:range
                  (:start
                   (:line 141 :character 8)
                   :end
                   (:line 141 :character 48))
                  :severity 4 :code "E0034" :codeDescription
                  (:href "https://doc.rust-lang.org/error-index.html#E0034")
                  :source "rustc" :message "candidate #2 is defined in an impl for the type `i64`" :relatedInformation
                  [(:location
                    (:uri "file:///home/zylthinking/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/saturating.rs" :range
                          (:start
                           (:line 853 :character 0)
                           :end
                           (:line 853 :character 76)))
                    :message "original diagnostic")])]))
[server-notification] Wed Sep 11 22:38:52 2024:

[zylthinking]

And it occurs in 08c7bbc2dbe4dcc89684 (tag: 2024-09-09) I have to say so because the RA shipped with stable 1.81 does reporting same errors but it runs quickly, finished in seconds.

I totally confused by all these.

[lnicola]

There's nothing in https://github.com/rust-lang/rust-analyzer/pull/17880/files that could cause this.

[roife]

I retested it, but still couldn't find any problems 🫤 It seems that r-a is reporting a lot of odd diagnostics here.

Do you have any configurations for your r-a? =

Or could it be an issue that occurred during the toolchain installation? Can you try removing the toolchain and reinstalling it to see if that helps?

Also, can you share your eglot and emacs versions?

[zylthinking]

The emacs is 29.3 built from code by myself. I noticed when I open eglot log, the mode line showing something 1.x M *EGLOT (proxy/(rust-m...rust-ts-mode)) events* , for example, showing 1.7M at first, then it changes to 1.5M, then 1.6M, then 1.4M ....

I guess this maybe the content size. If it's true, it means r-a repeatedly produce same diagnostics over and over again; which it should report just once.

At my last testing, it finally stopped, after about 30 minutes (and cpu usage decreased when it stopped), and it is the only time I did not kill -9 emacs or eglot-shutdown so I do't know whether it stopped by accident or others would stopped finally too.

The eglot log saved is a.zip attached above, and I think maybe it just the last output of r-a reporting.

That is my r-a configuration, nothing special.

(defun zylthinking/init-rust-mode ()
 (defalias 'rust-ts-mode 'rust-mode "disable rust-ts-mode if it's added to auto-mode-alist latter than me")
 (use-package rust-mode
   :hook
   (rust-mode . eglot-ensure)
   (rust-ts-mode . eglot-ensure)
   :init
   (setq rust-mode-treesitter-derive t)))

(defun my/project-try-local (dir)
  "Determine if DIR is a non-Git project."
  (catch 'ret
    (let ((pr-flags '((".project")
                      ("Cargo.toml")
                      ("compile_commands.json"))))
      (dolist (current-level pr-flags)
        (dolist (f current-level)
          (when-let ((root (locate-dominating-file dir f)))
            (message "project root: %s" root)
            (throw 'ret (cons 'local root))))))))
(setq project-find-functions '(my/project-try-local))
(advice-add 'projectile-mode :around (lambda (fn &rest any) (funcall fn -1)))

The r-a is built using cargo xtask install --server, because I installed it when r-a is not part of the toolchain. Then every-time I update rust, rustup report because I install r-a manually, so it will not install r-a for me, and I kept upgrading r-a by myself, everthing is OK until recently I upgrade it to tag 2024-09-02.

As I mentioned above, then I rollback to tag 2024-08-05, the problem disappear. Then I repeatedly built r-a in the time line and found the merge

commit https://github.com/rust-lang/rust-analyzer/commit/bd6fb363f072b7a48ac624ee46791187f0a0bbd4 has this issue, https://github.com/rust-lang/rust-analyzer/commit/9a090a287021772453450d580878de959cd82b8d has not (I used git log --graph so the sequence may differ with bare git log).

But that is on PC-1, the other day I used another PC-2 which has an emacs-29.1.90, and compiles r-a (tag 2024-09-09) and changed from rustic-mode to rust-mode, it seemed no problem, then I thought maybe the problem was a weakness of rustic.

But when I came home to do the same configuration on PC-1 and start using r-a (tag 2024-09-09), the problem appears. Then I notices the eglot log and weird size-changing in mode-line.

At last, I removed the r-a built by myself, and reinstall r-a shipped with stable 1.81, the problem gone. The step is:

1. remove ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rls (I don't know why is there, but when I saw it I rm it), then rustup component add rust-analyzer.
2. the rust-analyzer appears in ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin, but emacs reports servered died: -1
3. then I move rust-analyzer from ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin to ~/.cargo bin, still server died: -1
4. So I have to rustup uninstall stable && rustup install stable to reintall 1.81. I notice rust-analyzer still absent in ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin
5. Then I run ustup component add rust-analyzer, this time ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rust-analyzer appears.
6. And no server died: -1 appears again.

Then I reproduced the problem, I can still notice tons of log appears in eglot events buffer, but it stopped in seconds (not 30 minutes+). And the content size is more than 1M.

[mihaiolteanu]

I get a lot of CPU usage for eglot, too, after a system-wide update on arch-linux. I'm using eglot with javascript/typescript mode. Sometimes it hangs for seconds on end, to the point where I have to disable it as it's not usable anymore. I've had to reboot the laptop a few times as it was completely frozen.

emacs 30.1 with built-in eglot 1.17.30. Manually installing eglot 1.18 did not change anything.

[lnicola]

@mihaiolteanu I assume you're not using rust-analyzer?

[mihaiolteanu]

No, I'm not using Rust at all. Maybe it is not related to rust, is what I'm trying to say.