Merge #7723

7723: Fix typos r=lnicola a=azzamsa

I have checked all the documents inside `docs/` using `grammarly.com`.
There are many suggestions in each document (some of them are false positive). I choose to fix the typos only to avoid lengthy grammar discussions. I would like to suggest to the maintainers to take a look. It is worth it.

IMHO, it better to put the article into `grammarly.com` or `languagetool.org` before pushing :).

Co-authored-by: azzamsa <me@azzamsa.com>

Author: bors[bot]

docs/dev/architecture.md

@@ -209,7 +209,7 @@ If you want to use IDE parts of rust-analyzer via LSP, custom flatbuffers-based
 The API uses editor's terminology, it talks about offsets and string labels rather than in terms of definitions or types.
 It is effectively the view in MVC and viewmodel in [MVVM](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel).
 All arguments and return types are conceptually serializable.
-In particular, syntax tress and and hir types are generally absent from the API (but are used heavily in the implementation).
+In particular, syntax tress and hir types are generally absent from the API (but are used heavily in the implementation).
 Shout outs to LSP developers for popularizing the idea that "UI" is a good place to draw a boundary at.
 
 `ide` is also the first crate which has the notion of change over time.
@@ -230,7 +230,7 @@ This crate defines the `rust-analyzer` binary, so it is the **entry point**.
 It implements the language server.
 
 **Architecture Invariant:** `rust-analyzer` is the only crate that knows about LSP and JSON serialization.
-If you want to expose a datastructure `X` from ide to LSP, don't make it serializable.
+If you want to expose a data structure `X` from ide to LSP, don't make it serializable.
 Instead, create a serializable counterpart in `rust-analyzer` crate and manually convert between the two.
 
 `GlobalState` is the state of the server.
@@ -418,7 +418,7 @@ We use `always` and `never` macros instead of `assert` to gracefully recover fro
 
 ### Observability
 
-rust-analyzer is a long-running process, so its important to understand what's going on inside.
+rust-analyzer is a long-running process, so it is important to understand what's going on inside.
 We have several instruments for that.
 
 The event loop that runs rust-analyzer is very explicit.

docs/dev/style.md

@@ -41,7 +41,7 @@ For the second group, the change would be subjected to quite a bit of scrutiny a
 The new API needs to be right (or at least easy to change later).
 The actual implementation doesn't matter that much.
 It's very important to minimize the amount of changed lines of code for changes of the second kind.
-Often, you start doing a change of the first kind, only to realise that you need to elevate to a change of the second kind.
+Often, you start doing a change of the first kind, only to realize that you need to elevate to a change of the second kind.
 In this case, we'll probably ask you to split API changes into a separate PR.
 
 Changes of the third group should be pretty rare, so we don't specify any specific process for them.
@@ -102,7 +102,7 @@ Of course, applying Clippy suggestions is welcome as long as they indeed improve
 ## Minimal Tests
 
 Most tests in rust-analyzer start with a snippet of Rust code.
-This snippets should be minimal -- if you copy-paste a snippet of real code into the tests, make sure to remove everything which could be removed.
+These snippets should be minimal -- if you copy-paste a snippet of real code into the tests, make sure to remove everything which could be removed.
 
 It also makes sense to format snippets more compactly (for example, by placing enum definitions like `enum E { Foo, Bar }` on a single line),
 as long as they are still readable.
@@ -227,7 +227,7 @@ if idx >= len {
 }
 ```
 
-**Rationale:** its useful to see the invariant relied upon by the rest of the function clearly spelled out.
+**Rationale:** it's useful to see the invariant relied upon by the rest of the function clearly spelled out.
 
 ## Assertions