How to clean up the cache?

[BasileCooke]

I'm on Ubuntu 22.04, using the rust-analyzer extenstion in a git-versionned workspace where a workspace package A depends on another B.

I made a change on B, adding a field to a struct, without changing the version in cargo.toml, the project builds correctly but the extension show an error.

If I change the version of the B package, the extension is fixed, but when I go back to the previous version, it shows up again.

I tried to use "cargo clean" but it doesn't change anything.

Where is the cache for rust analyzer and how to clean it?

Thanks!

EDIT: forgot to mention I'm using VS code

[mohe2015]

Did you already try reloading/restarting your editor?

There could still be some actual issue but for me that "fixed" lots of stuff. (Mostly related to proc macros where this is intended)

[lnicola]

There is no cache, you might have edited Cargo's copy of B (under ~/.cargo/registry/src/, deleting that should be safe).

[BasileCooke]

Thanks for you answers 😄

Did you already try reloading/restarting your editor?

Of course, this hasn't change anything for me.

There is no cache

I don't see how it could behave the way it does without some cache somewhere. It defenitely remember the old code.

you might have edited Cargo's copy of B (under ~/.cargo/registry/src/, deleting that should be safe).

I tried to do cargo clean, then close vscode, then delete ~/.cargo/registry/cache, ~/.cargo/registry/index and ~/.cargo/registry/src. Still have the issue. Was very hopeful for this one :/

[lnicola]

cargo update -p B?

[BasileCooke]

cargo update -p B?

Didn't work 😢

[lnicola]

Does cargo build --all-targets work?

[BasileCooke]

Does cargo build --all-targets work?

Does not seem to work either :/

[lnicola]

You're on your own then. But remember that:

• Cargo.toml can specify a SHA/branch/tag for git dependencies
• Cargo.lock will store the SHA for those (cargo update should have bumped that though)

Also, you might want to check if you're using the workspace version of B, or if you're pulling it from crates.io.

[BasileCooke]

A and B are custom packages not pushed to crates.io. However if the commit sha1 is saved to Cargo.lock maybe the outdated code comes from the .git folder?

Is it safe to remove the Cargo.lock file?

[lnicola]

It will be created again, with the latest available versions. Keep the old one as a backup.

[BasileCooke]

Doesn't work though...

[mohe2015]

Can you show us your Cargo.toml files (or relevant excerpts)?

[BasileCooke]

I can show you a resume.

File architecture ->

.git
folder0/Cargo.toml
folder0/A/Cargo.toml
folder0/folder1/B/Cargo.toml
folder0/folder1/C/Cargo.toml
folder0/D/Cargo.toml

folder0/Cargo.toml ->

[workspace]
resolver = "2"

members = [
    "A",
    "folder1/B",
    "folder1/C",
]

exclude = ["D"]

[workspace.dependencies]
libLib = "=0.x.x"

folder0/A/Cargo.toml ->

[package]
name = "A"
version = "1.0.0"
authors = ["Me"]
edition = "2018"
description = "Main program"
homepage = "no_homepage"

[dependencies]
libLib .workspace = true

# Internal dependencies
B = { path = "../folder1/B/" }
C = { path = "../folder1/C/" }

folder0/folder1/B/Cargo.toml ->

[package]
name = "B"
version = "0.1.0"
authors = ["Me"]
edition = "2018"

[dependencies]
libLib.workspace = true

# Internal dependencies
C = { path = "../C/" }

folder0/folder1/C/Cargo.toml ->

[package]
name = "C"
version = "0.1.0"
edition = "2021"

[dependencies]
libLib.workspace = true

Don't know if its related or not but the edition is different in package C.

What happened is that the package B changed with a field added to a struct and the package A was updated accordingly. The code compiles but vscode shows an error in package A that says the field is missing.

Note: In the B changes, I did not change the version of the B package. When change it to, let's say, "0.1.1", vscode does not report the issue anymore. But if I change it back, the error is shown again.

[BasileCooke]

On a good note: When I change all the edition values to 2021, the error is not shown. When I revert it back it is still not shown. So this operation clears the cache at least. Not sure if it resolves the issue.

At least this gives me a workaround if it happens again 😄

[timstr]

I've been seeing a very similar error, involving a path to a git reposity in my Cargo.toml with branch = "main". I pushed some changes to the main branch of the repository, and my project builds fine using the new features. In VSCode, I can click on the name of a module in the git-based crate that I just added and go to its definition without problems. However, the name of the new module and other new features are all shown with red error squiggles and all the error messages you'd expect from Rust Analyzer keeping a stale copy of the code. This is still the case over a month after authoring those changes in git. I can work around it by hard-coding the git revision instead of the branch name but it's a nuisance. I tried temporarily removing various 'Cache' directories in ~/.config/Code to no avail.

Again, the project builds fine with the most recent changes in git, and in the above example, if I select the highlighed constants and go to its definition, I am taken to a copy of my most recent code.

Reopening VSCode didn't work. Uninstalling and reinstalling rust-analyzer didn't work.

I'm on Ubuntu 22.04, VSCode 1.85.1, rust-analyzer VSCode extension v0.3.1807

[timstr]

Seems like cargo update -p atomicslice did fix it for me. No more error squiggles, tooltips are accurate and up-to-date. This is weird, there are no recorded changes in my Cargo.lock file. Why would updating the git project through cargo make any difference when cargo already builds fine and Rust Analyzer is presenting stale information?

Spoke too soon, cargo update -p also doesn't fix the issue. I still have incorrect error squiggles in my code. Seems by all accounts that Rust Analyzer has saved a copy or the revision hash of old code and I can't figure out where.

[davidbarsky]

rust-analyzer doesn't cache rustc errors to the degree that you're describing. If anything, Cargo's caches might be messed up—have you run a Cargo clean?

[timstr]

Thank you @davidbarsky for following up, I just ran cargo clean and it seems to work! Afterwards, when reloading/relaunching VSCode and wating for rust-analizer to warm up, I consistently get correct tooltips and suggestions and no more out-of-date error squiggles. Thanks for the tip!

[BasileCooke]

Seems like it comes from the .cargo folder.

A collegue of mine had the issue and fixed it by removing the Cargo.lock, then removed $HOME.cargo/registry/src/index.crates.io-6f17d22bba15001f/chrono-0.4.31 and recompiled.

Next time I get this issue I'll try running cargo update -p && cargo clean.

[evbo]

Maybe this should be a separate issue I should open, but consider this use-case:

Mono-ish repo where you have separate Rust projects mixed with some Python projects:

root_folder:
    python_mod_a
    python_mod_b
    rust_mod_a
        Cargo.toml
    rust_mod_b
        Cargo.toml

In this case, no matter how many times I cd into rust_mod_a and type cargo clean or cargo update, it never seems to resolve squiggly red lines with a git branch dependency.

However, if I instead open VS Code just for the following folder:

rust_mod_a
    Cargo.toml

It instantly resolves squiggly red lines for a struct that it was previously outdated on / didn't recognize latest public fields for.

But if I switch back to opening root_folder, again the squiggly lines reappear...

So can rust-analyzer support these sorts of hybrid project structures with various modules located in deeper subfolders?

[evbo]

About my previous comment: I swear at one point it was no issue opening a mono-repo with deeper-nested Rust modules... So maybe this is a bug? I am on the latest prerelease FYI

[BasileCooke]

This behavior happened to me again and a cargo update && cargo clean did not help :/ But the technique to switch to and from a different edition did. It does seems to be related to switching in very different git branches.

I do have python code, and even rust to python binding in one package, so maybe it is related.

I do want to open the all project in VS code though, it is much more practical to me. As this happens not very often and I have a "solution" to fix this, it does not bother me as much but still feel like a bug.

Not being able to clean a state of rust analyzer seems like a feature missing though.

[mohe2015]

Can't find it in the issue comments, what error do you get exactly? Is it a cargo error or a rust analyzer error?

[mohe2015]

Maybe this should be a separate issue I should open, but consider this use-case:

Mono-ish repo where you have separate Rust projects mixed with some Python projects:

root_folder:
    python_mod_a
    python_mod_b
    rust_mod_a
        Cargo.toml
    rust_mod_b
        Cargo.toml

In this case, no matter how many times I cd into rust_mod_a and type cargo clean or cargo update, it never seems to resolve squiggly red lines with a git branch dependency.

However, if I instead open VS Code just for the following folder:

rust_mod_a
    Cargo.toml

It instantly resolves squiggly red lines for a struct that it was previously outdated on / didn't recognize latest public fields for.

But if I switch back to opening root_folder, again the squiggly lines reappear...

So can rust-analyzer support these sorts of hybrid project structures with various modules located in deeper subfolders?

Also depending on the error is something maybe depending on the current working directory? Like a proc macro or something? Or potentially rust-analyzer somewhere uses it in the wrong way.

Also if somebody could provide a reproduction example that would probably be great. Though I understand that's not always possible because of private code etc.

[BasileCooke]

The issue is that the the program compile fine (cargo build) but the rust analyzer extension on VS code shows errors, for instance a missing enum element.

The problem is that it happens very rarely on a big and private repository so I can't get a minimal code to reproduce the issue.

I don't think it is a big deal, however when that is happening, rust analyzer gets in a weird state that can't be cleared, or at least I didn't find how. The only trick I found to fix it is to change the edition of the individual internal packages of the workspace, and then change it back. Completely recloned our repo apparently worked for one of my collegue, but it is really not acceptable for me.

I'd really like a way to totally clean the "cache" that hides somewhere, and therefore fix the issue when it happens.

[evbo]

@mohe2015 I've caught the bug!

1. In VS Code I ctrl + click on the struct that purports a red squiggly field that should exist
2. It opens an Rust source file from an outdated commit located in ~/.cargo/git/checkouts/<repo>-<hash>/<commit-sha>
3. I grep in ~/.cargo and discover other projects with git dependencies on <repo> that I'm not currently working on
4. I open said projects and run cargo update on each of them. I did not need to push any changes remotely.
5. rm -rf ~/.cargo/git
6. Back in my original project, I Restart server and voila! No more cached old commits and no more red squiggly

Problem Tree:

root_folder:  # vs code opens this folder, so rust-analyzer must appease A and B simultaneously
    python_mod_a
    python_mod_b
    rust_mod_A  
        Cargo.toml  # depends on C git branch
    rust_mod_B 
        Cargo.toml  # depends on ../A and D git branch

rust_mod_C  # has not been cargo updated yet
    Cargo.lock  # depends on D git branch with older sha in lock file

rust_mod_D  # rust-analyzer tries to appease A by referencing older commit sha due to C, but that conflicts with B
    src    
        schema.rs  # contains updated struct but rust-analyzer ignores it since C still pointing at prev commit

So the bug occurs if you have other projects, that you're not even working on, that still have Cargo.lock files which point to the older commit SHA. You currently must cargo update all of them, even if you have no interest in working on them, or else it appears cargo will still cache the older commit.

running cargo build inside of root_folder has never failed, so there's something inconsistent with how rust-analyzer handles transitive git branch dependencies. That's the only part to this I can't pinpoint, but it certainly feels like a bug...

[cisaacson]

I had this issue as well, and what @evbo says works. I deleted the $HOME/.cargo/cache, Cargo.lock, ran cargo update, cargo clean, exited VS Code and when I came in the issue was solved. I am not sure which of those things worked, but I tried all of the other usual things first with no luck.

[goertzenator]

I thought I had a cache issue and looked everywhere for the old reference. It turns out I had added a weird settings to rust-analyzer months ago and forgot about it. Another place to look if you are stuck...