mirror of
https://github.com/rust-lang/rust-analyzer.git
synced 2025-09-29 13:25:09 +00:00
docs
This commit is contained in:
parent
03ea6bcbff
commit
8d61853509
2 changed files with 33 additions and 3 deletions
|
@ -1,6 +1,8 @@
|
||||||
//! ra_analyzer crate is the brain of Rust analyzer. It relies on the `salsa`
|
//! ra_analyzer crate provides "ide-centric" APIs for the rust-analyzer. What
|
||||||
//! crate, which provides and incremental on-demand database of facts.
|
//! 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 {
|
macro_rules! ctry {
|
||||||
($expr:expr) => {
|
($expr:expr) => {
|
||||||
match $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)]
|
#[derive(Debug)]
|
||||||
pub struct NavigationTarget {
|
pub struct NavigationTarget {
|
||||||
file_id: FileId,
|
file_id: FileId,
|
||||||
|
|
|
@ -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::{
|
use std::{
|
||||||
hash::{Hash, Hasher},
|
hash::{Hash, Hasher},
|
||||||
sync::Arc,
|
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)]
|
#[derive(Debug, Clone, PartialEq, Eq, Hash)]
|
||||||
pub(crate) struct FileSymbol {
|
pub(crate) struct FileSymbol {
|
||||||
pub(crate) name: SmolStr,
|
pub(crate) name: SmolStr,
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue