Reloading Cargo Project process stuck in updating crates.io index...

[LBruyne]

Environment

• 0.4.161.4292-212
• rustc 1.59.0-nightly (0fb1c371d 2021-12-06)
• IntelliJ IDEA 2021.2.1:
• MacOS. Big Sur 11.6

Problem description

After the update of plugin, when i open a new project in IDEA initially, the process of update crates.io is stuck. I believe i have started a web proxy so the network problem is not existed. The situation is that I can't scan source code of std crates using command+B now.

Steps to reproduce

Just open a new project in IDEA.

[edsion11]

I have the same problem too! So how can I know what happened?

[edsion11]

Good! I click the close icon(not the minimize icon), it goes well.

[LBruyne]

Good! I click the close icon(not the minimize icon), it goes well.

Well, i believe this problem is an incompatible between the nightly version and the plugin itself.

I try to revert to stable version and try reloading again, it goes well.

[xrl]

I see this issue as well on both rustup default nightly and rustup default stable rust environments

% rustc --version
rustc 1.59.0 (9d1b2106e 2022-02-23)

[xrl]

Ah, I didn't realize there was a ticket creation shortcut from intellij's help menu. Here's the magic blob it emitted:

* **IntelliJ Rust plugin version:** 0.4.165.4438-213
* **Rust toolchain version:** 1.59.0 (9d1b2106e 2022-02-23) aarch64-apple-darwin
* **IDE name and version:** IntelliJ IDEA 2021.3.2 Ultimate Edition (IU-213.6777.52)
* **Operating system:** macOS 12.2.1
* **Macro expansion engine:** new
* **Name resolution engine:** new

I will downgrade the resolution engine and see if that changes things.

~Edit: changing the rust engine fixed it:~

~and now it's not stuck in an indexing loop~

Second edit: nothing was fixed, once I opened a rust file it went back to the indexing loop

[xrl]

Downgrading intellij from 2021.3.2 to 2021.2.4 seems to have cured the problem. I can use the new rust engine.

[manoadamro]

same problem here, it's been updating crates.io index for about an hour now. What's weird is, the IDE is configured to use the same rust install as my terminal, and crates.io is up to date already, so I have no idea what it thinks it's doing

[kjzhaocn]

The latest version is 2022.3 and it also have this problem.But the plugin is work in PyCharm

[forsman5]

Was also encountering this same problem. I was able to fix it by updating intellij to the most recent version, then deleting the cargo registry as described here: https://github.com/rust-lang/rust/issues/64248#issuecomment-839392042, then running intellij as administrator. Then the cargo sync worked successfully for me.

[Areyana]

Do cargo check in console and run as admin worked for me, on last Idea version

[LeoLXSantiago]

try to delete the file at $HOME/.cargo called .package-cache then try reloading again, it goes well

[SteveLauC]

Still getting this issue with the latest RustRover (2023.2 EAP) :(

[gregdavisfromnj]

Using the now deprecated Rust plugin, in a dev container running/hosting CLion IDE backend, and with JetBrains Gateway 2023.2.4 as the client to the host IDE in the dev container, this problem or something very similar still exists. I can reproduce it by using a dev container that I cloned from gitlab.com (not github.com) using the new-dev-container flow directly from the JetBrains Gateway start up dialog. My project is not cloned before creating a local dev container from the local sources.

I am using Git+SSH protocol in all cases mentioned here, and not HTTPS, because I apparently like to do things the hard way.

I found that when I tried to manually git clone the crates.io-index repo in my dev container from the Terminal tab of the IDE, I was presented with a blocking prompt from the Git CLI to accept or decline the SSH server identity of github.com. I accept the key, which gets stored in ~/.ssh/known_hosts normally. Then, all of the actions inside of the CLion IDE that pertain to Rust, and result in the "updating crates.io index" activity to seem to hang, they now Just Work.

So, it seems that the Rust plugin and potentially RustRover IDE is waiting for command line user input which the user cannot see the prompt for, and cannot provide an input for.

As a suggestion for the folks at JetBrains... you might want to use approaches here if you are forking to execute Git commands, and present IDE users with a faster failure/error message. Please do not try to circumvent/skip the SSH fingerprint check as it will weaken security and provide a mechanism to potentially inject a supply chain attack (spoofing GitHub or crates.io at a proxy along the way, to provide forged/modified software dependencies).

As the author of the dev container definition that I am using to host the backend IDE, I will pre-load the official GitHub SSH key fingerprints to my container image known_hosts file(s) to avoid having to manually accept the keys in a prompt first.