Dependencies in cargo.toml reported as "No version matching" when the version number is increased.

[VictorGamerLOL]

Environment

• IntelliJ Rust plugin version: 0.4.197.5402-232
• Rust toolchain version: 1.70.0 (90c541806 2023-05-31) x86_64-unknown-linux-gnu
• IDE name and version: CLion 2023.2 EAP (CL-232.8453.115)
• Operating system: Linux 6.4.0-x64v1-xanmod2-2
• Macro expansion: enabled

Problem description

When I update dependencies in my cargo.toml by increasing their version number, the IDE will return warnings when i analyze the whole project in the cargo.toml saying that no version matching for the new ones was found. Does not matter if I run cargo update, invalidate IDE caches, reopen project, warning is still there as if the IDE's cargo registry never gets updated from the creation of the project.

Steps to reproduce

• Make a cargo.toml with a dependency that updates frequently and put ^ before the dependency's version.
• Wait for dependency to come up with a new update
• Increase version number of the dependency in the cargo.toml
• Warning shows up.

[a121bc]

我也出现了相同的问题，手动修改版本号后提示：No version matching ..* found for crate ***，怀疑是插件问题，旧版本的idea 2021使用的Rust plugin 0.4.164.4409-212没有此问题
IntelliJ Rust plugin version : 0.4.197.5401-231
IntelliJ IDEA 2023.1.3 (Community Edition)

[Maksim20023]

Hi! Unfortunately, there isn't enough information to investigate the causes of the issue you facing.
Due to the fact that such behavior can be caused by several reasons, please check if the following options according to your situation.
Do you use alternative registries?
Did the update of crates.io index fail? For example, terminated with an error or terminated manually due to excessive execution time?
This behavior may occur with dependencies that have been updated less than an hour ago (since the Rust plugin indexing crates.io every hour), and over time, the problem goes away.
If these options isn't for your situation, it would be great if you could send us additional logs, (For CLion: Help | Collect Logs and Diagnostic Data and same for IntelliJ IDEA) so we can take a look at what is going on. Please keep in mind that idea.log might contain sensitive information (e.g local paths). You can upload your logs to our https://uploads.jetbrains.com/. Uploaded files will only be accessible to JetBrains employees, and we guarantee the privacy of the data

[VictorGamerLOL]

There are no alternative registries, no cargo update failed, command line or via run cargo command from the plugin, no termination from error or me. Occurs with dependencies updated more than 5 days ago. I have uploaded fresh logs after a project has been opened in the cargo.toml file and cargo update has been ran. Upload id: 2023_07_04_53HpnXGWXRJ2tni4BTu99X (files: clion-logs-20230704-1804534029563639292331698.zip and 2 more)

I took another log afterwards after doing the same thing and running the problem checker on the whole project. Upload id: 2023_07_04_Nh6gEvoFC9dc2F29GatNTn (file: clion-logs-20230704-18160112899908384499152678.zip)

[Maksim20023]

Thank you for sending the logs. It helped me in reproducing and investigating. It seems that issue is related to the incorrect updating crates.io index.
As a workaround, please try cleaning Cargo registry cache.
By default, the registry folder can be found at the following path:
<your_username>/.cargo/registry.
You can either delete the "registry" directory or its contents. In any case, when launching the IDE, the necessary directories and files will be created automatically. Please note that during the first launch, indexing may take longer than usual (depending on the project).
Does it help?

[VictorGamerLOL]

Deleting the registry did fix the issue.

Is there a way to prevent such errors in the future or delete the registry every time this happens?

[Maksim20023]

At the moment, the reasons for such behaviour are unclear, and unfortunately, the methods to avoid it are also unknown. However, you can use the provided workaround if the issue returns.
I forwarded an issue and steps to reproduce to our development team to investigate. When we have more information, we'll add a reply to this ticket

[a121bc]

感谢，删除registry文件夹后确实有效

[rkarp]

I also get this problem sometimes. Interestingly, there is only a warning in Cargo.toml, but the new version of the library is listed correctly under "external libraries" and go to definition etc. in the code works fine. Autocomplete attempts in Cargo.toml will only list older versions of the library.

[Maksim20023]

Hi @rkarp! Thank you for letting us know. Could you please provide information about your environment (IDE, Rust plugin, and rust toolchain versions) where this issue occurred?

[rkarp]

Here's my environment:

• IntelliJ Rust plugin version: 0.4.198.5409-231
• Rust toolchain version: nightly-x86_64-pc-windows-msvc 1.73.0-nightly (33a2c2487 2023-07-12)
• IDE name and version: IntelliJ IDEA 2023.1.4 (Community Edition) Build #IC-231.9225.16
• Operating system: Windows 10 Pro x64

Right now it can't find "anyhow" v1.0.71 (it will only autocomplete up to 1.0.70). When I look into my ~/.cargo/registry subdirs I can find the following files, though:

• C:\Users\myuser\.cargo\registry\cache\index.crates.io-6f17d22bba15001f\anyhow-1.0.71.crate
• C:\Users\myuser\.cargo\registry\index\index.crates.io-6f17d22bba15001f\.cache\an\yh\anyhow (containing version string "1.0.71")
• C:\Users\myuser\.cargo\registry\src\index.crates.io-6f17d22bba15001f\anyhow-1.0.71

So I wonder what IntelliJ-Rust is missing here.

The problem does not seem to happen for all dependencies, and at some point it does seem to load newer versions. As in the issue problem description, cargo update, invalidate IDE caches etc. does not help, though.

[Maksim20023]

@rkarp Could you please specify whether you tried a workaround as mentioned in this post?

[rkarp]

About the workaround: After closing IntelliJ, backing up (renaming) ~/.cargo/registry and starting IntelliJ, the warning went away, but even after waiting a few minutes autocomplete showed no versions at all for "anyhow". Only after waiting 1h version autocomplete worked properly again.

If I switch back to the old ~/.cargo/registry it's the old broken behavior again. Even waiting 1h does not fix it.

Interestingly, ~\.cargo\registry\index\index.crates.io-6f17d22bba15001f\.cache\an\yh\anyhow is exactly the same in both the broken and the working version of ~/.cargo/registry, containing data about different "anyhow" versions, including the latest one.

[Maksim20023]

@rkarp Could you please send me "broken" cache for anyhow crate? It will help investigate the root of such behavior. You can upload files to our https://uploads.jetbrains.com/.

[rkarp]

@Maksim20023:
From my testing it seems that within ~/.cargo/registry only the index directory is relevant for this bug since I can reproduce the bug if I remove everything else. I've uploaded this minimized version: Upload id: 2023_07_18_wRcCZzQqStjGFm8RKdtCp2 (file: broken-registry.zip)

I've tested additionaly removing index/github.com-1ecc6299db9ec823, and that also seems to work as a workaround. After waiting for 1h and restarting IntelliJ, the newest "anyhow" version showed up in autocomplete.

[Maksim20023]

@rkarp Thank you for the files and your investigative work. It will be conducive to the process.

[p-kraszewski]

Hey everybody!

For those hit by this bug, when deleting ~/.cargo/registry/index is sufficient to fix. Did you use cargo-cache plugin, especially --autoclean-expensive or --gc options?

[rkarp]

@p-kraszewski: As for me, I've never used cargo-cache (or anything else that I think could mess with this cache / index).

[nicholasgrose]

I have observed this while using cargo-edit to update dependencies. I don't know if it always occurs, but it sure seems to occasionally. I also usually run cargo update, before cargo upgrade runs, which may or may not affect things.

[p-kraszewski]

I have observed this while using cargo-edit to update dependencies. I don't know if it always occurs, but it sure seems to occasionally. I also usually run cargo update, before cargo upgrade runs, which may or may not affect things.

Well, this particular is probably an expected behavior... When you change Cargo.toml (either directly or with tools like cargo-edit) there's a small Rust cog wheel icon floating in top-right corner of the editor area to re-scan dependencies. Option to auto-rescan might be helpful (as it already is for CMake file, for example).

Side-note - isn't cargo-edit integrated in some form in vanilla cargo for some months?

---

Answering myself: yes, cargo add/remove is now a part of cargo.

[chylex]

I tried deleting the registry folder from both Windows and WSL (I'm using a WSL toolchain), but it didn't fix the warning:

My registry cache folder: registry.tar.gz

[rkarp]

Another observation: The problem seemingly randomly fixed itself again a few days ago (I had been using the broken cache to see when this would happen). That was before the new Rust plugin update, and I hadn't done any toolchain changes / updates or anything else that I can think of that could have done this.

[octylFractal]

At least one cause appears to be the new sparse index that cargo uses. Using the command provided in rust-lang/cargo#12523 (CARGO_REGISTRIES_CRATES_IO_PROTOCOL=git cargo fetch) fixes the problem. I think either the plugin should issue this command itself when necessary, or it should allow using the new (and much quicker to update) index format.

[Maksim20023]

Hi!
Due to the launch of the RustRover and Rust support portal, we will no longer be using the GitHub issue tracker for support requests related to RustRover or the new Rust plugin. So, we moved this issue to our Rust issue tracker: link
We are also glad to say this issue has been fixed in RustRover and the new Rust plugin.