aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_db/src
diff options
context:
space:
mode:
Diffstat (limited to 'crates/ra_db/src')
-rw-r--r--crates/ra_db/src/cancellation.rs (renamed from crates/ra_db/src/cancelation.rs)6
-rw-r--r--crates/ra_db/src/input.rs22
-rw-r--r--crates/ra_db/src/lib.rs6
-rw-r--r--crates/ra_db/src/loc2id.rs4
4 files changed, 19 insertions, 19 deletions
diff --git a/crates/ra_db/src/cancelation.rs b/crates/ra_db/src/cancellation.rs
index 56ce27bff..8d38eebfb 100644
--- a/crates/ra_db/src/cancelation.rs
+++ b/crates/ra_db/src/cancellation.rs
@@ -8,11 +8,11 @@
8//! * user types next character, while syntax highlighting *is still in 8//! * user types next character, while syntax highlighting *is still in
9//! progress*. 9//! progress*.
10//! 10//!
11//! In this situation, we want to react to modification as quckly as possible. 11//! In this situation, we want to react to modification as quickly as possible.
12//! At the same time, in-progress results are not very interesting, because they 12//! At the same time, in-progress results are not very interesting, because they
13//! are invalidated by the edit anyway. So, we first cancel all in-flight 13//! are invalidated by the edit anyway. So, we first cancel all in-flight
14//! requests, and then apply modification knowing that it won't intrfere with 14//! requests, and then apply modification knowing that it won't interfere with
15//! any background processing (this bit is handled by salsa, see 15//! any background processing (this bit is handled by salsa, see the
16//! `BaseDatabase::check_canceled` method). 16//! `BaseDatabase::check_canceled` method).
17 17
18/// An "error" signifing that the operation was canceled. 18/// An "error" signifing that the operation was canceled.
diff --git a/crates/ra_db/src/input.rs b/crates/ra_db/src/input.rs
index 7c3dd9296..023183e29 100644
--- a/crates/ra_db/src/input.rs
+++ b/crates/ra_db/src/input.rs
@@ -1,9 +1,9 @@
1/// This modules specifies the input to rust-analyzer. In some sense, this is 1/// This module specifies the input to rust-analyzer. In some sense, this is
2/// **the** most important module, because all other fancy stuff is strictly 2/// **the** most important module, because all other fancy stuff is strictly
3/// derived from this input. 3/// derived from this input.
4/// 4///
5/// Note that neither this module, nor any other part of the analyzer's core do 5/// Note that neither this module, nor any other part of the analyzer's core do
6/// actual IO. See `vfs` and `project_model` in `ra_lsp_server` crate for how 6/// actual IO. See `vfs` and `project_model` in the `ra_lsp_server` crate for how
7/// actual IO is done and lowered to input. 7/// actual IO is done and lowered to input.
8use std::sync::Arc; 8use std::sync::Arc;
9 9
@@ -17,17 +17,17 @@ use rustc_hash::FxHashSet;
17/// `FileId` is an integer which uniquely identifies a file. File paths are 17/// `FileId` is an integer which uniquely identifies a file. File paths are
18/// messy and system-dependent, so most of the code should work directly with 18/// messy and system-dependent, so most of the code should work directly with
19/// `FileId`, without inspecting the path. The mapping between `FileId` and path 19/// `FileId`, without inspecting the path. The mapping between `FileId` and path
20/// and `SourceRoot` is constant. File rename is represented as a pair of 20/// and `SourceRoot` is constant. A file rename is represented as a pair of
21/// deletion/creation. 21/// deletion/creation.
22#[derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash)] 22#[derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash)]
23pub struct FileId(pub u32); 23pub struct FileId(pub u32);
24 24
25/// Files are grouped into source roots. A source root is a directory on the 25/// Files are grouped into source roots. A source root is a directory on the
26/// file systems which is watched for changes. Typically it corresponds to a 26/// file systems which is watched for changes. Typically it corresponds to a
27/// Cargo package. Source roots *might* be nested: in this case, file belongs to 27/// Rust crate. Source roots *might* be nested: in this case, a file belongs to
28/// the nearest enclosing source root. Path to files are always relative to a 28/// the nearest enclosing source root. Paths to files are always relative to a
29/// source root, and analyzer does not know the root path of the source root at 29/// source root, and the analyzer does not know the root path of the source root at
30/// all. So, a file from one source root can't refere a file in another source 30/// all. So, a file from one source root can't refer to a file in another source
31/// root by path. 31/// root by path.
32#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, PartialOrd, Ord)] 32#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, PartialOrd, Ord)]
33pub struct SourceRootId(pub u32); 33pub struct SourceRootId(pub u32);
@@ -38,15 +38,15 @@ pub struct SourceRoot {
38} 38}
39 39
40/// `CrateGraph` is a bit of information which turns a set of text files into a 40/// `CrateGraph` is a bit of information which turns a set of text files into a
41/// number of Rust crates. Each Crate is the `FileId` of it's root module, the 41/// number of Rust crates. Each crate is defined by the `FileId` of its root module,
42/// set of cfg flags (not yet implemented) and the set of dependencies. Note 42/// the set of cfg flags (not yet implemented) and the set of dependencies. Note
43/// that, due to cfg's, there might be several crates for a single `FileId`! As 43/// that, due to cfg's, there might be several crates for a single `FileId`! As
44/// in the rust-lang proper, a crate does not have a name. Instead, names are 44/// in the rust-lang proper, a crate does not have a name. Instead, names are
45/// specified on dependency edges. That is, a crate might be known under 45/// specified on dependency edges. That is, a crate might be known under
46/// different names in different dependant crates. 46/// different names in different dependent crates.
47/// 47///
48/// Note that `CrateGraph` is build-system agnostic: it's a concept of the Rust 48/// Note that `CrateGraph` is build-system agnostic: it's a concept of the Rust
49/// langauge proper, not a concept of the build system. In practice, we get 49/// language proper, not a concept of the build system. In practice, we get
50/// `CrateGraph` by lowering `cargo metadata` output. 50/// `CrateGraph` by lowering `cargo metadata` output.
51#[derive(Debug, Clone, Default, PartialEq, Eq)] 51#[derive(Debug, Clone, Default, PartialEq, Eq)]
52pub struct CrateGraph { 52pub struct CrateGraph {
diff --git a/crates/ra_db/src/lib.rs b/crates/ra_db/src/lib.rs
index e680d9fc3..fb8ea2496 100644
--- a/crates/ra_db/src/lib.rs
+++ b/crates/ra_db/src/lib.rs
@@ -1,5 +1,5 @@
1//! ra_db defines basic database traits. Concrete DB is defined by ra_ide_api. 1//! ra_db defines basic database traits. The concrete DB is defined by ra_ide_api.
2mod cancelation; 2mod cancellation;
3mod syntax_ptr; 3mod syntax_ptr;
4mod input; 4mod input;
5mod loc2id; 5mod loc2id;
@@ -8,7 +8,7 @@ pub mod mock;
8use ra_syntax::{TextUnit, TextRange, SourceFile, TreePtr}; 8use ra_syntax::{TextUnit, TextRange, SourceFile, TreePtr};
9 9
10pub use crate::{ 10pub use crate::{
11 cancelation::{Canceled, Cancelable}, 11 cancellation::{Canceled, Cancelable},
12 syntax_ptr::LocalSyntaxPtr, 12 syntax_ptr::LocalSyntaxPtr,
13 input::{ 13 input::{
14 FilesDatabase, FileId, CrateId, SourceRoot, SourceRootId, CrateGraph, Dependency, 14 FilesDatabase, FileId, CrateId, SourceRoot, SourceRootId, CrateGraph, Dependency,
diff --git a/crates/ra_db/src/loc2id.rs b/crates/ra_db/src/loc2id.rs
index 1d6761897..254c52629 100644
--- a/crates/ra_db/src/loc2id.rs
+++ b/crates/ra_db/src/loc2id.rs
@@ -5,7 +5,7 @@ use rustc_hash::FxHashMap;
5use ra_arena::{Arena, ArenaId}; 5use ra_arena::{Arena, ArenaId};
6 6
7/// There are two principle ways to refer to things: 7/// There are two principle ways to refer to things:
8/// - by their locatinon (module in foo/bar/baz.rs at line 42) 8/// - by their location (module in foo/bar/baz.rs at line 42)
9/// - by their numeric id (module `ModuleId(42)`) 9/// - by their numeric id (module `ModuleId(42)`)
10/// 10///
11/// The first one is more powerful (you can actually find the thing in question 11/// The first one is more powerful (you can actually find the thing in question
@@ -13,7 +13,7 @@ use ra_arena::{Arena, ArenaId};
13/// 13///
14/// `Loc2IdMap` allows us to have a cake an eat it as well: by maintaining a 14/// `Loc2IdMap` allows us to have a cake an eat it as well: by maintaining a
15/// bidirectional mapping between positional and numeric ids, we can use compact 15/// bidirectional mapping between positional and numeric ids, we can use compact
16/// representation wich still allows us to get the actual item 16/// representation which still allows us to get the actual item.
17#[derive(Debug)] 17#[derive(Debug)]
18struct Loc2IdMap<LOC, ID> 18struct Loc2IdMap<LOC, ID>
19where 19where