r-a constantly reindexes workspace when build script or proc macro is changed

[purplesyringa]

rust-analyzer version: rust-analyzer 1.84.0-nightly (1e4f10b 2024-10-29)

rustc version: rustc 1.84.0-nightly (1e4f10ba6 2024-10-29)

editor or extension: Sublime Text 4, but should apply to all editors

relevant settings: cache priming is enabled

r-a can temporary switch from being quiescent to not being quiescent when rebuilding proc macros:

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

Lines 71 to 79 in 17720ac

	pub(crate) fn is_quiescent(&self) -> bool {
	self.vfs_done
	&& self.last_reported_status.is_some()
	&& !self.fetch_workspaces_queue.op_in_progress()
	&& !self.fetch_build_data_queue.op_in_progress()
	&& !self.fetch_proc_macros_queue.op_in_progress()
	&& !self.discover_workspace_queue.op_in_progress()
	&& self.vfs_progress_config_version >= self.vfs_config_version
	}

When the proc macros are rebuilt, it will become quiescent again and trigger cache priming:

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

Lines 408 to 418 in 17720ac

	if self.is_quiescent() {
	let became_quiescent = !was_quiescent;
	if became_quiescent {
	if self.config.check_on_save(None) {
	// Project has loaded properly, kick off initial flycheck
	self.flycheck.iter().for_each(|flycheck| flycheck.restart_workspace(None));
	}
	if self.config.prefill_caches() {
	self.prime_caches_queue.request_op("became quiescent".to_owned(), ());
	}
	}

Cache priming has no protections against being activated more than once, so this leads to reindexing (and sometimes even rebuilding) the whole workspace (including totally unrelated crates and dependencies) every time a proc macro or a build script is changed. This causes immense lag and makes r-a almost unusable for writing proc macros.

[purplesyringa]

Sounds like a regular bug to me, but also

@rustbot label +A-perf

for visibility and searching

[Veykril]

You want to disable the rust-analyzer.cargo.buildScripts.rebuildOnSave setting. We need to rebuild build scripts / proc macros if their sources change as the output is used by the source code (build scripts being run affect the environement, proc-macros are invokved in source) and as such it is required to rebuild them to be up to date with the project's semantics.

Cache priming has no protections against being activated more than once,

Re-requesting cache priming while its already under way / requested is fine. request_op only sets a flag, it doesn't trigger a task itself.

[purplesyringa]

I'm not opposed to rebuilding the build scripts/proc macros, that's fast and it works fine. The problem is reindexing, which takes about 10 seconds for me. I might have misdiagnosed the bug, but I can assure you that I see "indexing: ..." from scratch in logs every time I hit Ctrl-S, soon after the scripts are rebuilt. If you're sure this isn't the underlying problem, are there any pointers to debug this further?