From 0b8fbb4fad97d2980f0070a23f5365a5ed887e2a Mon Sep 17 00:00:00 2001 From: Marcus Klaas de Vries Date: Wed, 9 Jan 2019 00:47:12 +0100 Subject: Fix typos in ARCHITECTURE.md and a number of crates specifically: gen_lsp_server, ra_arena, ra_cli, ra_db, ra_hir --- crates/ra_db/src/cancelation.rs | 44 ---------------------------------------- crates/ra_db/src/cancellation.rs | 44 ++++++++++++++++++++++++++++++++++++++++ crates/ra_db/src/input.rs | 22 ++++++++++---------- crates/ra_db/src/lib.rs | 6 +++--- crates/ra_db/src/loc2id.rs | 4 ++-- 5 files changed, 60 insertions(+), 60 deletions(-) delete mode 100644 crates/ra_db/src/cancelation.rs create mode 100644 crates/ra_db/src/cancellation.rs (limited to 'crates/ra_db') diff --git a/crates/ra_db/src/cancelation.rs b/crates/ra_db/src/cancelation.rs deleted file mode 100644 index 56ce27bff..000000000 --- a/crates/ra_db/src/cancelation.rs +++ /dev/null @@ -1,44 +0,0 @@ -//! Utility types to support cancellation. -//! -//! In a typical IDE use-case, requests and modification happen concurrently, as -//! in the following scenario: -//! -//! * user types a character, -//! * a syntax highlighting process is started -//! * user types next character, while syntax highlighting *is still in -//! progress*. -//! -//! In this situation, we want to react to modification as quckly as possible. -//! At the same time, in-progress results are not very interesting, because they -//! are invalidated by the edit anyway. So, we first cancel all in-flight -//! requests, and then apply modification knowing that it won't intrfere with -//! any background processing (this bit is handled by salsa, see -//! `BaseDatabase::check_canceled` method). - -/// An "error" signifing that the operation was canceled. -#[derive(Clone, PartialEq, Eq, Hash)] -pub struct Canceled { - _private: (), -} - -pub type Cancelable = Result; - -impl Canceled { - pub(crate) fn new() -> Canceled { - Canceled { _private: () } - } -} - -impl std::fmt::Display for Canceled { - fn fmt(&self, fmt: &mut std::fmt::Formatter<'_>) -> std::fmt::Result { - fmt.write_str("canceled") - } -} - -impl std::fmt::Debug for Canceled { - fn fmt(&self, fmt: &mut std::fmt::Formatter<'_>) -> std::fmt::Result { - write!(fmt, "Canceled") - } -} - -impl std::error::Error for Canceled {} diff --git a/crates/ra_db/src/cancellation.rs b/crates/ra_db/src/cancellation.rs new file mode 100644 index 000000000..8d38eebfb --- /dev/null +++ b/crates/ra_db/src/cancellation.rs @@ -0,0 +1,44 @@ +//! Utility types to support cancellation. +//! +//! In a typical IDE use-case, requests and modification happen concurrently, as +//! in the following scenario: +//! +//! * user types a character, +//! * a syntax highlighting process is started +//! * user types next character, while syntax highlighting *is still in +//! progress*. +//! +//! In this situation, we want to react to modification as quickly as possible. +//! At the same time, in-progress results are not very interesting, because they +//! are invalidated by the edit anyway. So, we first cancel all in-flight +//! requests, and then apply modification knowing that it won't interfere with +//! any background processing (this bit is handled by salsa, see the +//! `BaseDatabase::check_canceled` method). + +/// An "error" signifing that the operation was canceled. +#[derive(Clone, PartialEq, Eq, Hash)] +pub struct Canceled { + _private: (), +} + +pub type Cancelable = Result; + +impl Canceled { + pub(crate) fn new() -> Canceled { + Canceled { _private: () } + } +} + +impl std::fmt::Display for Canceled { + fn fmt(&self, fmt: &mut std::fmt::Formatter<'_>) -> std::fmt::Result { + fmt.write_str("canceled") + } +} + +impl std::fmt::Debug for Canceled { + fn fmt(&self, fmt: &mut std::fmt::Formatter<'_>) -> std::fmt::Result { + write!(fmt, "Canceled") + } +} + +impl std::error::Error for 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 @@ -/// This modules specifies the input to rust-analyzer. In some sense, this is +/// This module specifies the input to rust-analyzer. In some sense, this is /// **the** most important module, because all other fancy stuff is strictly /// derived from this input. /// /// Note that neither this module, nor any other part of the analyzer's core do -/// actual IO. See `vfs` and `project_model` in `ra_lsp_server` crate for how +/// actual IO. See `vfs` and `project_model` in the `ra_lsp_server` crate for how /// actual IO is done and lowered to input. use std::sync::Arc; @@ -17,17 +17,17 @@ use rustc_hash::FxHashSet; /// `FileId` is an integer which uniquely identifies a file. File paths are /// messy and system-dependent, so most of the code should work directly with /// `FileId`, without inspecting the path. The mapping between `FileId` and path -/// and `SourceRoot` is constant. File rename is represented as a pair of +/// and `SourceRoot` is constant. A file rename is represented as a pair of /// deletion/creation. #[derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash)] pub struct FileId(pub u32); /// Files are grouped into source roots. A source root is a directory on the /// file systems which is watched for changes. Typically it corresponds to a -/// Cargo package. Source roots *might* be nested: in this case, file belongs to -/// the nearest enclosing source root. Path to files are always relative to a -/// source root, and analyzer does not know the root path of the source root at -/// all. So, a file from one source root can't refere a file in another source +/// Rust crate. Source roots *might* be nested: in this case, a file belongs to +/// the nearest enclosing source root. Paths to files are always relative to a +/// source root, and the analyzer does not know the root path of the source root at +/// all. So, a file from one source root can't refer to a file in another source /// root by path. #[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, PartialOrd, Ord)] pub struct SourceRootId(pub u32); @@ -38,15 +38,15 @@ pub struct SourceRoot { } /// `CrateGraph` is a bit of information which turns a set of text files into a -/// number of Rust crates. Each Crate is the `FileId` of it's root module, the -/// set of cfg flags (not yet implemented) and the set of dependencies. Note +/// number of Rust crates. Each crate is defined by the `FileId` of its root module, +/// the set of cfg flags (not yet implemented) and the set of dependencies. Note /// that, due to cfg's, there might be several crates for a single `FileId`! As /// in the rust-lang proper, a crate does not have a name. Instead, names are /// specified on dependency edges. That is, a crate might be known under -/// different names in different dependant crates. +/// different names in different dependent crates. /// /// Note that `CrateGraph` is build-system agnostic: it's a concept of the Rust -/// langauge proper, not a concept of the build system. In practice, we get +/// language proper, not a concept of the build system. In practice, we get /// `CrateGraph` by lowering `cargo metadata` output. #[derive(Debug, Clone, Default, PartialEq, Eq)] 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 @@ -//! ra_db defines basic database traits. Concrete DB is defined by ra_ide_api. -mod cancelation; +//! ra_db defines basic database traits. The concrete DB is defined by ra_ide_api. +mod cancellation; mod syntax_ptr; mod input; mod loc2id; @@ -8,7 +8,7 @@ pub mod mock; use ra_syntax::{TextUnit, TextRange, SourceFile, TreePtr}; pub use crate::{ - cancelation::{Canceled, Cancelable}, + cancellation::{Canceled, Cancelable}, syntax_ptr::LocalSyntaxPtr, input::{ 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; use ra_arena::{Arena, ArenaId}; /// There are two principle ways to refer to things: -/// - by their locatinon (module in foo/bar/baz.rs at line 42) +/// - by their location (module in foo/bar/baz.rs at line 42) /// - by their numeric id (module `ModuleId(42)`) /// /// The first one is more powerful (you can actually find the thing in question @@ -13,7 +13,7 @@ use ra_arena::{Arena, ArenaId}; /// /// `Loc2IdMap` allows us to have a cake an eat it as well: by maintaining a /// bidirectional mapping between positional and numeric ids, we can use compact -/// representation wich still allows us to get the actual item +/// representation which still allows us to get the actual item. #[derive(Debug)] struct Loc2IdMap where -- cgit v1.2.3