From 8d6185350953391d0dd405cf790a69bb65d88a36 Mon Sep 17 00:00:00 2001 From: Aleksey Kladov Date: Thu, 3 Jan 2019 12:57:30 +0300 Subject: docs --- crates/ra_analysis/src/lib.rs | 13 ++++++++++--- crates/ra_analysis/src/symbol_index.rs | 23 +++++++++++++++++++++++ 2 files changed, 33 insertions(+), 3 deletions(-) (limited to 'crates') 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 @@ -//! ra_analyzer crate is the brain of Rust analyzer. It relies on the `salsa` -//! crate, which provides and incremental on-demand database of facts. - +//! ra_analyzer crate provides "ide-centric" APIs for the rust-analyzer. What +//! powers this API are the `RootDatabase` struct, which defines a `salsa` +//! database, and the `ra_hir` crate, where majority of the analysis happens. +//! However, IDE specific bits of the analysis (most notably completion) happen +//! in this crate. macro_rules! ctry { ($expr:expr) => { match $expr { @@ -219,6 +221,11 @@ impl Query { } } +/// `NavigationTarget` represents and element in the editor's UI whihc you can +/// click on to navigate to a particular piece of code. +/// +/// Typically, a `NavigationTarget` corresponds to some element in the source +/// code, like a function or a struct, but this is not strictly required. #[derive(Debug)] pub struct NavigationTarget { 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 @@ +//! This module handles fuzzy-searching of functions, structs and other symbols +//! by name across the whole workspace and dependencies. +//! +//! It works by building an incrementally-updated text-search index of all +//! symbols. The backbone of the index is the **awesome** `fst` crate by +//! @BurntSushi. +//! +//! In a nutshell, you give a set of strings to the `fst`, and it builds a +//! finite state machine describing this set of strtings. The strings which +//! could fuzzy-match a pattern can also be described by a finite state machine. +//! What is freakingly cool is that you can now traverse both state machines in +//! lock-step to enumerate the strings which are both in the input set and +//! fuzz-match the query. Or, more formally, given two langauges described by +//! fsts, one can build an product fst which describes the intersection of the +//! languages. +//! +//! `fst` does not support cheap updating of the index, but it supports unioning +//! of state machines. So, to account for changing source code, we build an fst +//! for each library (which is assumed to never change) and an fst for each rust +//! file in the current workspace, and run a query aginst the union of all +//! thouse fsts. use std::{ hash::{Hash, Hasher}, sync::Arc, @@ -160,6 +181,8 @@ fn is_type(kind: SyntaxKind) -> bool { } } +/// The actual data that is stored in the index. It should be as compact as +/// possible. #[derive(Debug, Clone, PartialEq, Eq, Hash)] pub(crate) struct FileSymbol { pub(crate) name: SmolStr, -- cgit v1.2.3