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.

[lnicola]

This might be a real RA bug. cargo add makes it reload the first time, but then stops working. Saving from Code works, bu that sends a textDocument/didSave, of course.

But Code does send some funny notifications:

# cargo add serde
Trace - 8:45:27 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "file:///Projects/hello/Cargo.toml",
            "type": 1
        },
        {
            "uri": "file:///Projects/hello/Cargo.toml",
            "type": 1
        },
        {
            "uri": "file:///Projects/hello/Cargo.toml",
            "type": 1
        },
        {
            "uri": "file:///Projects/hello/Cargo.toml",
            "type": 1
        }
    ]
}


[Trace - 8:45:27 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "file:///Projects/hello/Cargo.lock",
            "type": 2
        },
        {
            "uri": "file:///Projects/hello/Cargo.lock",
            "type": 2
        },
        {
            "uri": "file:///Projects/hello/Cargo.lock",
            "type": 2
        },
        {
            "uri": "file:///Projects/hello/Cargo.lock",
            "type": 2
        }
    ]
}


# cargo rm serde
[Trace - 8:45:41 PM] Sending notification 'workspace/didChangeWatchedFiles'.
Params: {
    "changes": [
        {
            "uri": "file:///Projects/hello/Cargo.toml",
            "type": 1
        },
        {
            "uri": "file:///Projects/hello/Cargo.lock",
            "type": 2
        },
        {
            "uri": "file:///Projects/hello/Cargo.toml",
            "type": 1
        },
        {
            "uri": "file:///Projects/hello/Cargo.lock",
            "type": 2
        },
        {
            "uri": "file:///Projects/hello/Cargo.toml",
            "type": 1
        },
        {
            "uri": "file:///Projects/hello/Cargo.lock",
            "type": 2
        },
        {
            "uri": "file:///Projects/hello/Cargo.toml",
            "type": 1
        },
        {
            "uri": "file:///Projects/hello/Cargo.lock",
            "type": 2
        }
    ]
}

So we never see a Changed event for Cargo.toml on cargo add, but we do on cargo rm.

[Veykril]

Interesting notification indeed but not necessarily wrong. I wonder if we get confused by invalidating a path multiple times in a loop

[Veykril]

Hmm, I do see a bug here that could cause this, though im confused that cargo rm works then ...

[Veykril]

Hmm, actually why is VSCode sending us events for the files being created and modified instead of just created? That seems weird (not that it matters to us here)

[lnicola]

cargo rm also doesn't work. And yeah, I'd expect Code to de-dup them.

[Veykril]

OOOOOH now I also see why r-a doesn't realize that a new file was created for a module via the diagnostic quickfix if it was created by vscode. It probably sends us multiple notifications for the file which causes us to enter a created entry in the VFS, and then the following invalidation re-sets the entry causing us to switch from created to modified since it already exists in the VFS ...

I've been bothered by that for ages 😄