diff options
Diffstat (limited to 'crates/ra_db')
-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.rs | 22 | ||||
-rw-r--r-- | crates/ra_db/src/lib.rs | 6 | ||||
-rw-r--r-- | crates/ra_db/src/loc2id.rs | 4 |
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. |
8 | use std::sync::Arc; | 8 | use 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)] |
23 | pub struct FileId(pub u32); | 23 | pub 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)] |
33 | pub struct SourceRootId(pub u32); | 33 | pub 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)] |
52 | pub struct CrateGraph { | 52 | pub 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. |
2 | mod cancelation; | 2 | mod cancellation; |
3 | mod syntax_ptr; | 3 | mod syntax_ptr; |
4 | mod input; | 4 | mod input; |
5 | mod loc2id; | 5 | mod loc2id; |
@@ -8,7 +8,7 @@ pub mod mock; | |||
8 | use ra_syntax::{TextUnit, TextRange, SourceFile, TreePtr}; | 8 | use ra_syntax::{TextUnit, TextRange, SourceFile, TreePtr}; |
9 | 9 | ||
10 | pub use crate::{ | 10 | pub 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; | |||
5 | use ra_arena::{Arena, ArenaId}; | 5 | use 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)] |
18 | struct Loc2IdMap<LOC, ID> | 18 | struct Loc2IdMap<LOC, ID> |
19 | where | 19 | where |