Version `0.3.1992` rust-analyzer process spins out of control in macOS VSCode

[ospfranco]

rust-analyzer version: 0.3.1992

rustc version: rustc 1.78.0 (9b00956e5 2024-04-29)

editor or extension: VSCode

relevant settings: Standard Rustup installation

repository link (if public, optional): n/a

code snippet to reproduce:
n/a

VSCode updated my extensions today and on the latest rust-analyzer version things are spinning out of control:

I've worked around it by downgrading the version on VSCode itself:

[jeromecornuz]

Same happens on Windows and Linux (rustc 1.78.0 (9b00956e5 2024-04-29))

[TsafrirA]

I was having a similar issue with Windows, VSCode, WSL Ubuntu.

[meuschke]

Same issue here

[lnicola]

Can anyone trigger it reliably? A public repository causing the issue or a bisection would be appreciated.

[Veykril]

Otherwise capturing backtraces of the running threads would help

[rami3l]

Can anyone trigger it reliably? A public repository causing the issue or a bisection would be appreciated.

@lnicola I haven't had the chance to dive into the details yet, but can confirm that rust-lang/rustup is one of the repos that has broken 2024-06-10...

PS: I use :MasonInstall to install an r-a distribution on Neovim, which I believe is just a direct download from your releases page. I just performed a downgrade by executing :MasonInstall rust-analyzer@2024-06-03 and now everything is working alright again.

OS: macOS 14.5.0

[roife]

By git bisect, I find that the problem may originate from 23a5f31.

[wtdcode]

Downgrading saves my day... r-a easily occupies my 7950x in a few minutes with the latest release =(

OS: Ubuntu 2404, bare metal.

[Oakchris1955]

I have the same problem on Debian Linux. Downgrading to v0.3.1983 fixes the issue.

[roife]

The problem might be in the infinite loop:

rust-analyzer/crates/rust-analyzer/src/config.rs

Lines 2562 to 2569 in 14a1f45

	while let Some(source_root_id) = par {
	par = self.source_root_parent_map.get(&source_root_id).copied();
	if let Some((config, _)) = self.ratoml_files.get(&source_root_id) {
	if let Some(value) = config.$field.as_ref() {
	return value;
	}
	}
	}

.

[roife]

The issue might be in this function: it returns a map {source_root: parent_of_source_root}, but sometimes dir might be equal to parent, which cause the infinite loop we’re seeing above.

Also, the variable i here seems weird, and I’m not sure what it's for. 👀

rust-analyzer/crates/load-cargo/src/lib.rs

Lines 284 to 306 in 14a1f45

	/// Maps local source roots to their parent source roots by bytewise comparing of root paths .
	/// If a `SourceRoot` doesn't have a parent and is local then it is not contained in this mapping but it can be asserted that it is a root `SourceRoot`.
	pub fn source_root_parent_map(&self) -> FxHashMap<SourceRootId, SourceRootId> {
	let roots = self.fsc.roots();
	let mut i = 0;
	roots
	.iter()
	.enumerate()
	.filter(|(_, (_, id))| self.local_filesets.contains(id))
	.filter_map(|(idx, (root, root_id))| {
	// We are interested in parents if they are also local source roots.
	// So instead of a non-local parent we may take a local ancestor as a parent to a node.
	roots[..idx].iter().find_map(|(root2, root2_id)| {
	i += 1;
	if self.local_filesets.contains(root2_id) && root.starts_with(root2) {
	return Some((root_id, root2_id));
	}
	None
	})
	})
	.map(|(&child, &parent)| (SourceRootId(child as u32), SourceRootId(parent as u32)))
	.collect()
	}

[hamsterjiang23]

同样问题，搞了两小时，换了个旧版本修复了。。无语