Merge rust-lang#473

473: Partial typo fix r=matklad a=marcusklaas

This fixes some typos. Mostly in documentation, but also some code is affected (`defenition` was used in a few method names).

Co-authored-by: Marcus Klaas de Vries <[email protected]>

Author: bors[bot]

ARCHITECTURE.md

@@ -1,6 +1,6 @@
 # Architecture
 
-This document describes high-level architecture of rust-analyzer.
+This document describes the high-level architecture of rust-analyzer.
 If you want to familiarize yourself with the code base, you are just
 in the right place!
 
@@ -12,10 +12,10 @@ On the highest level, rust-analyzer is a thing which accepts input source code
 from the client and produces a structured semantic model of the code.
 
 More specifically, input data consists of a set of test files (`(PathBuf,
-String)` pairs) and an information about project structure, the so called
-`CrateGraph`. Crate graph specifies which files are crate roots, which cfg flags
-are specified for each crate (TODO: actually implement this) and what are
-dependencies between the crates. The analyzer keeps all these input data in
+String)` pairs) and information about project structure, captured in the so called
+`CrateGraph`. The crate graph specifies which files are crate roots, which cfg
+flags are specified for each crate (TODO: actually implement this) and what
+dependencies exist between the crates. The analyzer keeps all this input data in
 memory and never does any IO. Because the input data is source code, which
 typically measures in tens of megabytes at most, keeping all input data in
 memory is OK.
@@ -28,16 +28,16 @@ declarations, etc.
 The client can submit a small delta of input data (typically, a change to a
 single file) and get a fresh code model which accounts for changes.
 
-Underlying engine makes sure that model is computed lazily (on-demand) and can
-be quickly updated for small modifications.
+The underlying engine makes sure that model is computed lazily (on-demand) and
+can be quickly updated for small modifications.
 
 
 ## Code generation
 
 Some of the components of this repository are generated through automatic
 processes. These are outlined below:
 
-- `gen-syntax`: The kinds of tokens are reused in several places, so a generator
+- `gen-syntax`: The kinds of tokens that are reused in several places, so a generator
   is used. We use tera templates to generate the files listed below, based on
   the grammar described in [grammar.ron]:
   - [ast/generated.rs][ast generated] in `ra_syntax` based on
@@ -58,17 +58,16 @@ processes. These are outlined below:
 ### `crates/ra_syntax`
 
 Rust syntax tree structure and parser. See
-[RFC](https://github.com/rust-lang/rfcs/pull/2256) for some design
-notes.
+[RFC](https://github.com/rust-lang/rfcs/pull/2256) for some design notes.
 
 - [rowan](https://github.com/rust-analyzer/rowan) library is used for constructing syntax trees.
-- `grammar` module is the actual parser. It is a hand-written recursive descent parsers, which
-  produces a sequence of events like "start node X", "finish not Y". It works similarly to  [kotlin parser](https://github.com/JetBrains/kotlin/blob/4d951de616b20feca92f3e9cc9679b2de9e65195/compiler/frontend/src/org/jetbrains/kotlin/parsing/KotlinParsing.java),
-  which is a good source for inspiration for dealing with syntax errors and incomplete input. Original [libsyntax parser](https://github.com/rust-lang/rust/blob/6b99adeb11313197f409b4f7c4083c2ceca8a4fe/src/libsyntax/parse/parser.rs)
+- `grammar` module is the actual parser. It is a hand-written recursive descent parser, which
+  produces a sequence of events like "start node X", "finish not Y". It works similarly to [kotlin's parser](https://github.com/JetBrains/kotlin/blob/4d951de616b20feca92f3e9cc9679b2de9e65195/compiler/frontend/src/org/jetbrains/kotlin/parsing/KotlinParsing.java),
+  which is a good source of inspiration for dealing with syntax errors and incomplete input. Original [libsyntax parser](https://github.com/rust-lang/rust/blob/6b99adeb11313197f409b4f7c4083c2ceca8a4fe/src/libsyntax/parse/parser.rs)
   is what we use for the definition of the Rust language.
 - `parser_api/parser_impl` bridges the tree-agnostic parser from `grammar` with `rowan` trees.
   This is the thing that turns a flat list of events into a tree (see `EventProcessor`)
-- `ast` a type safe API on top of the raw `rowan` tree.
+- `ast` provides a type safe API on top of the raw `rowan` tree.
 - `grammar.ron` RON description of the grammar, which is used to
   generate `syntax_kinds` and `ast` modules, using `cargo gen-syntax` command.
 - `algo`: generic tree algorithms, including `walk` for O(1) stack
@@ -90,7 +89,7 @@ fixes a bug in the grammar.
 We use the [salsa](https://github.com/salsa-rs/salsa) crate for incremental and
 on-demand computation. Roughly, you can think of salsa as a key-value store, but
 it also can compute derived values using specified functions. The `ra_db` crate
-provides a basic infrastructure for interacting with salsa. Crucially, it
+provides basic infrastructure for interacting with salsa. Crucially, it
 defines most of the "input" queries: facts supplied by the client of the
 analyzer. Reading the docs of the `ra_db::input` module should be useful:
 everything else is strictly derived from those inputs.
@@ -102,7 +101,7 @@ HIR provides high-level "object oriented" access to Rust code.
 The principal difference between HIR and syntax trees is that HIR is bound to a
 particular crate instance. That is, it has cfg flags and features applied (in
 theory, in practice this is to be implemented). So, the relation between
-syntax and HIR is many-to-one. The `source_binder` modules is responsible for
+syntax and HIR is many-to-one. The `source_binder` module is responsible for
 guessing a HIR for a particular source position.
 
 Underneath, HIR works on top of salsa, using a `HirDatabase` trait.
@@ -111,12 +110,12 @@ Underneath, HIR works on top of salsa, using a `HirDatabase` trait.
 
 A stateful library for analyzing many Rust files as they change. `AnalysisHost`
 is a mutable entity (clojure's atom) which holds the current state, incorporates
-changes and handles out `Analysis` --- an immutable and consistent snapshot of
-world state at a point in time, which actually powers analysis.
+changes and hands out `Analysis` --- an immutable and consistent snapshot of
+the world state at a point in time, which actually powers analysis.
 
 One interesting aspect of analysis is its support for cancellation. When a
 change is applied to `AnalysisHost`, first all currently active snapshots are
-cancelled. Only after all snapshots are dropped the change actually affects the
+canceled. Only after all snapshots are dropped the change actually affects the
 database.
 
 APIs in this crate are IDE centric: they take text offsets as input and produce
@@ -142,7 +141,7 @@ An LSP implementation which wraps `ra_ide_api` into a langauge server protocol.
 
 ### `crates/ra_vfs`
 
-Although `hir` and `ra_ide_api` don't do any io, we need to be able to read
+Although `hir` and `ra_ide_api` don't do any IO, we need to be able to read
 files from disk at the end of the day. This is what `ra_vfs` does. It also
 manages overlays: "dirty" files in the editor, whose "true" contents is
 different from data on disk.
@@ -175,16 +174,16 @@ VS Code plugin
 ## Common workflows
 
 To try out VS Code extensions, run `cargo install-code`.  This installs both the
-`ra_lsp_server` binary and VS Code extension. To install only the binary, use
+`ra_lsp_server` binary and the VS Code extension. To install only the binary, use
 `cargo install --path crates/ra_lsp_server --force`
 
 To see logs from the language server, set `RUST_LOG=info` env variable. To see
 all communication between the server and the client, use
-`RUST_LOG=gen_lsp_server=debug` (will print quite a bit of stuff).
+`RUST_LOG=gen_lsp_server=debug` (this will print quite a bit of stuff).
 
 To run tests, just `cargo test`.
 
-To work on VS Code extension, launch code inside `editors/code` and use `F5` to
+To work on the VS Code extension, launch code inside `editors/code` and use `F5` to
 launch/debug. To automatically apply formatter and linter suggestions, use `npm
 run fix`.
 

crates/gen_lsp_server/src/lib.rs

@@ -78,10 +78,10 @@ pub use crate::{
 };
 
 /// Main entry point: runs the server from initialization to shutdown.
-/// To attach server to standard input/output streams, use `stdio_transport`
+/// To attach server to standard input/output streams, use the `stdio_transport`
 /// function to create corresponding `sender` and `receiver` pair.
 ///
-///`server` should use `handle_shutdown` function to handle the `Shutdown`
+/// `server` should use the `handle_shutdown` function to handle the `Shutdown`
 /// request.
 pub fn run_server(
     caps: ServerCapabilities,
@@ -104,7 +104,7 @@ pub fn run_server(
     Ok(())
 }
 
-/// if `req` is `Shutdown`, respond to it and return `None`, otherwise return `Some(req)`
+/// If `req` is `Shutdown`, respond to it and return `None`, otherwise return `Some(req)`
 pub fn handle_shutdown(req: RawRequest, sender: &Sender<RawMessage>) -> Option<RawRequest> {
     match req.cast::<Shutdown>() {
         Ok((id, ())) => {

crates/gen_lsp_server/src/msg.rs

@@ -54,7 +54,7 @@ pub enum ErrorCode {
     ServerErrorEnd = -32000,
     ServerNotInitialized = -32002,
     UnknownErrorCode = -32001,
-    RequestCancelled = -32800,
+    RequestCanceled = -32800,
     ContentModified = -32801,
 }
 

crates/ra_db/src/cancelation.rs renamed to 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,15 +5,15 @@ 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
 /// by id), but the second one is so much more compact.
 ///
 /// `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

crates/ra_hir/src/code_model_api.rs

@@ -13,8 +13,8 @@ use crate::{
     ty::InferenceResult,
 };
 
-/// hir::Crate describes a single crate. It's the main inteface with which
-/// crate's dependencies interact. Mostly, it should be just a proxy for the
+/// hir::Crate describes a single crate. It's the main interface with which
+/// a crate's dependencies interact. Mostly, it should be just a proxy for the
 /// root module.
 #[derive(Debug, Clone, PartialEq, Eq, Hash)]
 pub struct Crate {
@@ -75,9 +75,10 @@ impl Module {
     }
 
     /// Returns a node which defines this module. That is, a file or a `mod foo {}` with items.
-    pub fn defenition_source(&self, db: &impl HirDatabase) -> Cancelable<(FileId, ModuleSource)> {
-        self.defenition_source_impl(db)
+    pub fn definition_source(&self, db: &impl HirDatabase) -> Cancelable<(FileId, ModuleSource)> {
+        self.definition_source_impl(db)
     }
+
     /// Returns a node which declares this module, either a `mod foo;` or a `mod foo {}`.
     /// `None` for the crate root.
     pub fn declaration_source(
@@ -91,20 +92,24 @@ impl Module {
     pub fn krate(&self, db: &impl HirDatabase) -> Cancelable<Option<Crate>> {
         self.krate_impl(db)
     }
+
     /// Topmost parent of this module. Every module has a `crate_root`, but some
-    /// might miss `krate`. This can happen if a module's file is not included
-    /// into any module tree of any target from Cargo.toml.
+    /// might be missing `krate`. This can happen if a module's file is not included
+    /// in the module tree of any target in Cargo.toml.
     pub fn crate_root(&self, db: &impl HirDatabase) -> Cancelable<Module> {
         self.crate_root_impl(db)
     }
+
     /// Finds a child module with the specified name.
     pub fn child(&self, db: &impl HirDatabase, name: &Name) -> Cancelable<Option<Module>> {
         self.child_impl(db, name)
     }
+
     /// Finds a parent module.
     pub fn parent(&self, db: &impl HirDatabase) -> Cancelable<Option<Module>> {
         self.parent_impl(db)
     }
+
     pub fn path_to_root(&self, db: &impl HirDatabase) -> Cancelable<Vec<Module>> {
         let mut res = vec![self.clone()];
         let mut curr = self.clone();
@@ -114,13 +119,16 @@ impl Module {
         }
         Ok(res)
     }
+
     /// Returns a `ModuleScope`: a set of items, visible in this module.
     pub fn scope(&self, db: &impl HirDatabase) -> Cancelable<ModuleScope> {
         self.scope_impl(db)
     }
+
     pub fn resolve_path(&self, db: &impl HirDatabase, path: &Path) -> Cancelable<PerNs<DefId>> {
         self.resolve_path_impl(db, path)
     }
+
     pub fn problems(
         &self,
         db: &impl HirDatabase,
@@ -140,6 +148,7 @@ impl StructField {
     pub fn name(&self) -> &Name {
         &self.name
     }
+
     pub fn type_ref(&self) -> &TypeRef {
         &self.type_ref
     }
@@ -160,18 +169,21 @@ impl VariantData {
             _ => &[],
         }
     }
+
     pub fn is_struct(&self) -> bool {
         match self {
             VariantData::Struct(..) => true,
             _ => false,
         }
     }
+
     pub fn is_tuple(&self) -> bool {
         match self {
             VariantData::Tuple(..) => true,
             _ => false,
         }
     }
+
     pub fn is_unit(&self) -> bool {
         match self {
             VariantData::Unit => true,

crates/ra_hir/src/code_model_impl/module.rs

@@ -37,7 +37,7 @@ impl Module {
         Ok(Some(link.name(&module_tree).clone()))
     }
 
-    pub fn defenition_source_impl(
+    pub fn definition_source_impl(
         &self,
         db: &impl HirDatabase,
     ) -> Cancelable<(FileId, ModuleSource)> {

crates/ra_hir/src/db.rs

@@ -26,6 +26,7 @@ pub trait HirDatabase: SyntaxDatabase
         type HirSourceFileQuery;
         use fn HirFileId::hir_source_file;
     }
+
     fn expand_macro_invocation(invoc: MacroCallId) -> Option<Arc<MacroExpansion>> {
         type ExpandMacroCallQuery;
         use fn crate::macros::expand_macro_invocation;
@@ -80,10 +81,12 @@ pub trait HirDatabase: SyntaxDatabase
         type InputModuleItemsQuery;
         use fn query_definitions::input_module_items;
     }
+
     fn item_map(source_root_id: SourceRootId) -> Cancelable<Arc<ItemMap>> {
         type ItemMapQuery;
         use fn query_definitions::item_map;
     }
+
     fn module_tree(source_root_id: SourceRootId) -> Cancelable<Arc<ModuleTree>> {
         type ModuleTreeQuery;
         use fn crate::module_tree::ModuleTree::module_tree_query;