fix: Fix formatting requests hanging when r-a is still starting

The reason for that was that we were calculating the crate defmaps
of the file we are saving by accident causing us to get stuck waiting
on their expensive computation, while we only need the relevant crate
id.
This commit is contained in:
Lukas Wirth 2022-10-17 17:53:50 +02:00
parent 40cbeb5b3d
commit a762baca02
8 changed files with 17 additions and 24 deletions

View file

@ -1,9 +1,8 @@
use hir::Semantics;
use ide_db::{
base_db::{CrateId, FileId, FilePosition},
base_db::{CrateId, FileId, FileLoader, FilePosition},
RootDatabase,
};
use itertools::Itertools;
use syntax::{
algo::find_node_at_offset,
ast::{self, AstNode},
@ -55,9 +54,8 @@ pub(crate) fn parent_module(db: &RootDatabase, position: FilePosition) -> Vec<Na
}
/// Returns `Vec` for the same reason as `parent_module`
pub(crate) fn crate_for(db: &RootDatabase, file_id: FileId) -> Vec<CrateId> {
let sema = Semantics::new(db);
sema.to_module_defs(file_id).map(|module| module.krate().into()).unique().collect()
pub(crate) fn crates_for(db: &RootDatabase, file_id: FileId) -> Vec<CrateId> {
db.relevant_crates(file_id).iter().copied().collect()
}
#[cfg(test)]
@ -147,7 +145,7 @@ $0
mod foo;
"#,
);
assert_eq!(analysis.crate_for(file_id).unwrap().len(), 1);
assert_eq!(analysis.crates_for(file_id).unwrap().len(), 1);
}
#[test]
@ -162,6 +160,6 @@ mod baz;
mod baz;
"#,
);
assert_eq!(analysis.crate_for(file_id).unwrap().len(), 2);
assert_eq!(analysis.crates_for(file_id).unwrap().len(), 2);
}
}