aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorazzamsa <[email protected]>2021-02-20 10:53:19 +0000
committerazzamsa <[email protected]>2021-02-20 10:53:19 +0000
commitae50b1850352e5786bd4fe37689cbf9ce9686900 (patch)
tree08820c3d409182a4ea87c82927707685c844324e /docs
parent20a911f3cc2beb0409ab71cc1560648374745f7f (diff)
Fix typos
Diffstat (limited to 'docs')
-rw-r--r--docs/dev/architecture.md6
-rw-r--r--docs/dev/style.md6
2 files changed, 6 insertions, 6 deletions
diff --git a/docs/dev/architecture.md b/docs/dev/architecture.md
index 081ee5b9d..ead12616e 100644
--- a/docs/dev/architecture.md
+++ b/docs/dev/architecture.md
@@ -209,7 +209,7 @@ If you want to use IDE parts of rust-analyzer via LSP, custom flatbuffers-based
209The API uses editor's terminology, it talks about offsets and string labels rather than in terms of definitions or types. 209The API uses editor's terminology, it talks about offsets and string labels rather than in terms of definitions or types.
210It is effectively the view in MVC and viewmodel in [MVVM](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel). 210It is effectively the view in MVC and viewmodel in [MVVM](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel).
211All arguments and return types are conceptually serializable. 211All arguments and return types are conceptually serializable.
212In particular, syntax tress and and hir types are generally absent from the API (but are used heavily in the implementation). 212In particular, syntax tress and hir types are generally absent from the API (but are used heavily in the implementation).
213Shout outs to LSP developers for popularizing the idea that "UI" is a good place to draw a boundary at. 213Shout outs to LSP developers for popularizing the idea that "UI" is a good place to draw a boundary at.
214 214
215`ide` is also the first crate which has the notion of change over time. 215`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**.
230It implements the language server. 230It implements the language server.
231 231
232**Architecture Invariant:** `rust-analyzer` is the only crate that knows about LSP and JSON serialization. 232**Architecture Invariant:** `rust-analyzer` is the only crate that knows about LSP and JSON serialization.
233If you want to expose a datastructure `X` from ide to LSP, don't make it serializable. 233If you want to expose a data structure `X` from ide to LSP, don't make it serializable.
234Instead, create a serializable counterpart in `rust-analyzer` crate and manually convert between the two. 234Instead, create a serializable counterpart in `rust-analyzer` crate and manually convert between the two.
235 235
236`GlobalState` is the state of the server. 236`GlobalState` is the state of the server.
@@ -418,7 +418,7 @@ We use `always` and `never` macros instead of `assert` to gracefully recover fro
418 418
419### Observability 419### Observability
420 420
421rust-analyzer is a long-running process, so its important to understand what's going on inside. 421rust-analyzer is a long-running process, so it is important to understand what's going on inside.
422We have several instruments for that. 422We have several instruments for that.
423 423
424The event loop that runs rust-analyzer is very explicit. 424The event loop that runs rust-analyzer is very explicit.
diff --git a/docs/dev/style.md b/docs/dev/style.md
index 73ce59b87..dd71e3932 100644
--- a/docs/dev/style.md
+++ b/docs/dev/style.md
@@ -41,7 +41,7 @@ For the second group, the change would be subjected to quite a bit of scrutiny a
41The new API needs to be right (or at least easy to change later). 41The new API needs to be right (or at least easy to change later).
42The actual implementation doesn't matter that much. 42The actual implementation doesn't matter that much.
43It's very important to minimize the amount of changed lines of code for changes of the second kind. 43It's very important to minimize the amount of changed lines of code for changes of the second kind.
44Often, you start doing a change of the first kind, only to realise that you need to elevate to a change of the second kind. 44Often, you start doing a change of the first kind, only to realize that you need to elevate to a change of the second kind.
45In this case, we'll probably ask you to split API changes into a separate PR. 45In this case, we'll probably ask you to split API changes into a separate PR.
46 46
47Changes of the third group should be pretty rare, so we don't specify any specific process for them. 47Changes 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
102## Minimal Tests 102## Minimal Tests
103 103
104Most tests in rust-analyzer start with a snippet of Rust code. 104Most tests in rust-analyzer start with a snippet of Rust code.
105This 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. 105These 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.
106 106
107It also makes sense to format snippets more compactly (for example, by placing enum definitions like `enum E { Foo, Bar }` on a single line), 107It also makes sense to format snippets more compactly (for example, by placing enum definitions like `enum E { Foo, Bar }` on a single line),
108as long as they are still readable. 108as long as they are still readable.
@@ -227,7 +227,7 @@ if idx >= len {
227} 227}
228``` 228```
229 229
230**Rationale:** its useful to see the invariant relied upon by the rest of the function clearly spelled out. 230**Rationale:** it's useful to see the invariant relied upon by the rest of the function clearly spelled out.
231 231
232## Assertions 232## Assertions
233 233