aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--crates/ra_analysis/src/lib.rs13
-rw-r--r--crates/ra_analysis/src/symbol_index.rs23
2 files changed, 33 insertions, 3 deletions
diff --git a/crates/ra_analysis/src/lib.rs b/crates/ra_analysis/src/lib.rs
index 343fd28bb..61af676b2 100644
--- a/crates/ra_analysis/src/lib.rs
+++ b/crates/ra_analysis/src/lib.rs
@@ -1,6 +1,8 @@
1//! ra_analyzer crate is the brain of Rust analyzer. It relies on the `salsa` 1//! ra_analyzer crate provides "ide-centric" APIs for the rust-analyzer. What
2//! crate, which provides and incremental on-demand database of facts. 2//! powers this API are the `RootDatabase` struct, which defines a `salsa`
3 3//! database, and the `ra_hir` crate, where majority of the analysis happens.
4//! However, IDE specific bits of the analysis (most notably completion) happen
5//! in this crate.
4macro_rules! ctry { 6macro_rules! ctry {
5 ($expr:expr) => { 7 ($expr:expr) => {
6 match $expr { 8 match $expr {
@@ -219,6 +221,11 @@ impl Query {
219 } 221 }
220} 222}
221 223
224/// `NavigationTarget` represents and element in the editor's UI whihc you can
225/// click on to navigate to a particular piece of code.
226///
227/// Typically, a `NavigationTarget` corresponds to some element in the source
228/// code, like a function or a struct, but this is not strictly required.
222#[derive(Debug)] 229#[derive(Debug)]
223pub struct NavigationTarget { 230pub struct NavigationTarget {
224 file_id: FileId, 231 file_id: FileId,
diff --git a/crates/ra_analysis/src/symbol_index.rs b/crates/ra_analysis/src/symbol_index.rs
index 1b6815bbf..10d8e8059 100644
--- a/crates/ra_analysis/src/symbol_index.rs
+++ b/crates/ra_analysis/src/symbol_index.rs
@@ -1,3 +1,24 @@
1//! This module handles fuzzy-searching of functions, structs and other symbols
2//! by name across the whole workspace and dependencies.
3//!
4//! It works by building an incrementally-updated text-search index of all
5//! symbols. The backbone of the index is the **awesome** `fst` crate by
6//! @BurntSushi.
7//!
8//! In a nutshell, you give a set of strings to the `fst`, and it builds a
9//! finite state machine describing this set of strtings. The strings which
10//! could fuzzy-match a pattern can also be described by a finite state machine.
11//! What is freakingly cool is that you can now traverse both state machines in
12//! lock-step to enumerate the strings which are both in the input set and
13//! fuzz-match the query. Or, more formally, given two langauges described by
14//! fsts, one can build an product fst which describes the intersection of the
15//! languages.
16//!
17//! `fst` does not support cheap updating of the index, but it supports unioning
18//! of state machines. So, to account for changing source code, we build an fst
19//! for each library (which is assumed to never change) and an fst for each rust
20//! file in the current workspace, and run a query aginst the union of all
21//! thouse fsts.
1use std::{ 22use std::{
2 hash::{Hash, Hasher}, 23 hash::{Hash, Hasher},
3 sync::Arc, 24 sync::Arc,
@@ -160,6 +181,8 @@ fn is_type(kind: SyntaxKind) -> bool {
160 } 181 }
161} 182}
162 183
184/// The actual data that is stored in the index. It should be as compact as
185/// possible.
163#[derive(Debug, Clone, PartialEq, Eq, Hash)] 186#[derive(Debug, Clone, PartialEq, Eq, Hash)]
164pub(crate) struct FileSymbol { 187pub(crate) struct FileSymbol {
165 pub(crate) name: SmolStr, 188 pub(crate) name: SmolStr,