Autocompletion for newly added crate doesn't work after `cargo add` it, but works after editing Cargo.toml directly

[zjp-CN]

rust-analyzer version: 0.3.1641-standalone (144526c 2023-08-28)

rustc version: rustc 1.73.0-nightly (e4c144684 2023-08-04)

relevant settings: no

Autocompletion for newly added crate doesn't work after cargo add it, but works after editing Cargo.toml directly.

• [no]nvim + cargo add: https://vimeo.com/860654937?share=copy
• [no]vscode + cargo add: https://vimeo.com/860654907?share=copy
• [yes]nvim + edit Cargo.toml: https://vimeo.com/860654966?share=copy
• [yes]vscode + edit Cargo.toml: https://vimeo.com/860654994?share=copy

The problem is found in https://users.rust-lang.org/t/nvim-rust-analyzer-fails-to-provide-autocomplete-for-new-crates/99329

[lnicola]

Can't reproduce in VS Code on my system:

Just to make sure, which extension are you using?

[danielepintore]

Hello, I can reproduce the issue while using a clean lazyvim installation, apparently it doesn't reload the work space, because if i manually type :CargoReload the problem is fixed. But i can confirm that in VS code everything works.
In addition i have tested using other nvim setups like nvchad and my nvim config and the problem is present. Maybe it is related to some package used when configuring nvim?
Ps. I have noted that while using nvim the problem is present even when editing the cargo.toml file.

[lnicola]

Could also be related to the client-side watching implementation. Although TBH I remember occasionally having issues in Code too.

[zjp-CN]

which extension are you using?

I don't use VSCode, so there are only some basic extensions. I tried again today in VSCode, autocompletion still won't work after only Cargo add.

VSCode Info
Version: 1.82.0 (system setup)
Commit: 8b617bd08fd9e3fc94d14adb8d358b56e3f72314
Date: 2023-09-06T22:07:07.438Z
Electron: 25.8.0
ElectronBuildId: 23503258
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Windows_NT x64 10.0.22621

apparently it doesn't reload the work space, because if i manually type :CargoReload the problem is fixed

Oh, it's true. Because even though I don't run :CargoReload in nvim manually, only saving Cargo.toml to tigger reloading will fix the problem (both in nvim and VSCode!).

---

It's just weird that RA already noticed the newly added crate without any import error, but didn't provide completion information.

[TanixLu]

I have the same issue on both my desktop and laptop. They share the same info on the following aspects.

Windows version:

Edition	Windows 11 Pro
Version	22H2
OS build	22621.2283
Experience	Windows Feature Experience Pack 1000.22662.1000.0

VSCode version:

Version: 1.82.2 (user setup)
Commit: abd2f3db4bdb28f9e95536dfa84d8479f1eb312d
Date: 2023-09-14T05:55:25.390Z
Electron: 25.8.1
ElectronBuildId: 23779380
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Windows_NT x64 10.0.22621

rust-analyzer version: v0.3.1673

I did a clean install of VSCode on my laptop, so the settings are the default ones. I only installed the rust-analyzer extension to do the test. I’ve tried both the user and system installer of VSCode, but the result is the same. Cargo remove also has the same problem.

[viruscamp]

Reproduced:

Version: 1.82.2 (user setup)
Commit: abd2f3db4bdb28f9e95536dfa84d8479f1eb312d
Date: 2023-09-14T05:55:25.390Z
Electron: 25.8.1
ElectronBuildId: 23779380
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Windows_NT x64 10.0.19045

With rust-analyzer extention v0.3.1673, bin rust-analyzer 1.74.0-nightly (5ae769f0 2023-09-26) and bundled bin rust-analyzer 0.3.1673-standalone (862a3004e 2023-09-24).

Something maybe useful:

• cargo add cast
• write cast::i6(4); in a function, cast::i6 does not exist. You will get the message in VSCode Output Rust Analyzer Language Server:

[ERROR rust_analyzer::main_loop] flycheck 0: File with cargo diagnostic not found in VFS: file not found: d:\rust\cargo\registry\src\rsproxy.cn-0dccff568467c15b\cast-0.3.0\src\lib.rs

[Veykril]

This is most likely a problem with VSCode's file watcher implementation, you can work around this by telling rust-analyzer to do server side filewatching instead via "rust-analyzer.files.watcher": "server". (If the issue still occurs afterwards then there is also a bug in r-a)

[zjp-CN]

Thanks for explaining. Till now, I've tested these

• the problem still exists in latest VSCode, but using server filewatching can solve it
• no problem with neovim any more (maybe some fixes in nvim happened)

So I'm closing this.