For loop over hashmap breaks rust-analyzer

[ElusiveMori]

I've run into a very strange issue with a single file in my project and a single loop (!) causing 100% CPU usage on ra_lsp_server and a memory leak of around 10 MB/s.

I've been able to narrow it down to a very strange, but simple pattern of code:

use std::collections::HashMap;

fn evil(garbage: HashMap<u32, u32>) {
    for (very, evil) in &garbage {
    }
}

This simple piece of code has been responsible for at least 3 OOM-related crashes on my system so far :(

I'm using rust-analyzer built on the latest master, and running on Linux. Here's hoping this bug report is helpful.

[flodiebold]

Hm. It sounds like it could be another Chalk loop, but I can't reproduce this with just this code in a fresh project. Do type hints or hover show the correct types for the loop variables? Can you run ra_cli analysis-stats in the project repo?

[ElusiveMori]

That's strange, but now I can't reproduce it in the simple example as well. I guess there were some other side-effects, though I kept restarting RA to make sure everything was "clean".

If you're curious to take a look for yourself, I've made a somewhat "minimal" example in https://github.com/ElusiveMori/ceres-wc3/tree/rustanalyzer-bug , the culprit is in ceres-core/src/compiler.rs, function emit_script. I've tried to strip it down as much as I could to illustrate the issue.

Answering your questions:

• Type hints do not show in that particular loop in my code.
• Running ra_cli analysis-stats seems to hang on emit_script, though I haven't left it running long enough to be able to tell for sure.

Curiously enough, if I rewrite the loop like this:

for (id, compiled_module) in self.compiled_modules.iter() {
}

then the issue goes away.

[flodiebold]

Yeah, it's very likely to be the same (kind of) problem as #1684, then.

[ElusiveMori]

@flodiebold I think I found a reproducible example, if you need one:

use atoi::atoi;

pub fn evil(sauron: &[u8]) -> u32 {
    atoi(&sauron).unwrap()
}

I couldn't remove the atoi dependency without breaking reproducibility, even if I copied the function signature of atoi.

Manually specifying the generic parameter like atoi::<u32>(&sauron) makes the issue go away.

Tested using ra_cli analysis-stats

[flodiebold]

It's an interesting example, thanks!

[flodiebold]

This was fixed by #1800.