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/cancellation.rs

@@ -8,11 +8,11 @@
 //!   * user types next character, while syntax highlighting *is still in
 //!     progress*.
 //!
-//! In this situation, we want to react to modification as quckly as possible.
+//! 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 intrfere with
-//! any background processing (this bit is handled by salsa, see
+//! 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.

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 {

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,

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<LOC, ID>
 where