Auto merge of #17374 - Veykril:configs, r=Veykril

Allow choosing logical cores for num threads config
This commit is contained in:
bors 2024-06-11 08:49:19 +00:00
commit ba1c56c83a
7 changed files with 145 additions and 111 deletions

View file

@ -19,13 +19,6 @@ pub struct CallItem {
pub ranges: Vec<TextRange>,
}
impl CallItem {
#[cfg(test)]
pub(crate) fn debug_render(&self) -> String {
format!("{} : {:?}", self.target.debug_render(), self.ranges)
}
}
pub(crate) fn call_hierarchy(
db: &RootDatabase,
position: FilePosition,
@ -159,6 +152,10 @@ mod tests {
expected_incoming: Expect,
expected_outgoing: Expect,
) {
fn debug_render(item: crate::CallItem) -> String {
format!("{} : {:?}", item.target.debug_render(), item.ranges)
}
let (analysis, pos) = fixture::position(ra_fixture);
let mut navs = analysis.call_hierarchy(pos).unwrap().unwrap().info;
@ -169,12 +166,10 @@ mod tests {
let item_pos =
FilePosition { file_id: nav.file_id, offset: nav.focus_or_full_range().start() };
let incoming_calls = analysis.incoming_calls(item_pos).unwrap().unwrap();
expected_incoming
.assert_eq(&incoming_calls.into_iter().map(|call| call.debug_render()).join("\n"));
expected_incoming.assert_eq(&incoming_calls.into_iter().map(debug_render).join("\n"));
let outgoing_calls = analysis.outgoing_calls(item_pos).unwrap().unwrap();
expected_outgoing
.assert_eq(&outgoing_calls.into_iter().map(|call| call.debug_render()).join("\n"));
expected_outgoing.assert_eq(&outgoing_calls.into_iter().map(debug_render).join("\n"));
}
#[test]

View file

@ -284,7 +284,7 @@ impl Analysis {
})
}
pub fn parallel_prime_caches<F>(&self, num_worker_threads: u8, cb: F) -> Cancellable<()>
pub fn parallel_prime_caches<F>(&self, num_worker_threads: usize, cb: F) -> Cancellable<()>
where
F: Fn(ParallelPrimeCachesProgress) + Sync + std::panic::UnwindSafe,
{

View file

@ -28,7 +28,7 @@ pub(super) fn highlight_escape_string<T: IsString>(
pub(super) fn highlight_escape_char(stack: &mut Highlights, char: &Char, start: TextSize) {
if char.value().is_err() {
// We do not emit invalid escapes highlighting here. The lexer would likely be in a bad
// state and this token contains junks, since `'` is not a reliable delimiter (consider
// state and this token contains junk, since `'` is not a reliable delimiter (consider
// lifetimes). Nonetheless, parser errors should already be emitted.
return;
}