rust analyzer doesn't update after running `cargo update -p crate_xxx`

[zhiqiangxu]

When I run cargo update -p crate_xxx to update a specific crate, rust analyzer doesn't update, thus it shows syntax error when cargo build works normally.

[ChayimFriedman2]

Is this new? Can you try a rust-analyzer version before this week?

[zhiqiangxu]

Looks like it's automatically updated, it's already latest.

UPDATE

The issue still exists:

[ChayimFriedman2]

I meant to ask whether this issue exists with previous versions of rust-analyzer. You can install them by right-clicking the extension then choosing "Install Specific Version...".

[zhiqiangxu]

I tried the 0.3.2337 version, still the same. Is there a way to force it to update?

[Veykril]

Can you check if setting

    "rust-analyzer.files.watcher": "server",

in your config makes a difference?

[zhiqiangxu]

Can you check if setting

"rust-analyzer.files.watcher": "server",

in your config makes a difference?

When restart, it initially seems ok, but if I edit&save, the red lines come out again:

[zhiqiangxu]

The issue is gone if I specify the git dependency with rev instead of branch .(that is, manually update the commit hash each time when updated)

[davidbarsky]

Can you check if setting

"rust-analyzer.files.watcher": "server",

in your config makes a difference?

When restart, it initially seems ok, but if I edit&save, the red lines come out again:

Those red squiggles are coming from Cargo, not rust-analyzer. Cargo often doesn't pick up source control-driven invalidations.

[zhiqiangxu]

Those red squiggles are coming from Cargo, not rust-analyzer. Cargo often doesn't pick up source control-driven invalidations.

But cargo build gives no error.

[davidbarsky]

Ah, then that is a rust-analyzer issue. Given that this reproduces from before this week's change, this is likely an issue with whatever file watcher used here: either server or editor. The server's file watcher is annoyingly racy and most editors'—especially VS Code's—do not send all invalidation events.

We plan on moving to a more robust file watcher in the future, but this might be a bit ways off for now. I'll close this issue in the meantime, as it's known problem.