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

zjp-CN commented 1 year ago

rust-analyzer version: 0.3.1641-standalone (144526c90 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 commented 1 year ago

Can't reproduce in VS Code on my system:

Just to make sure, which extension are you using?

danielepintore commented 1 year ago

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 commented 1 year ago

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

zjp-CN commented 1 year ago

which extension are you using?

20230910143709

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 9 months ago

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 commented 6 months ago

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 commented 6 months ago

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

Veykril commented 6 months ago

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

Veykril commented 6 months ago

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 commented 6 months ago

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

Veykril commented 6 months ago

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 😄

rust-lang / rust-analyzer

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