Mirrors/rust-analyzer
2
0
Fork 0
mirror of https://github.com/rust-lang/rust-analyzer synced 2024-11-16 09:48:10 +00:00
Code Issues Projects Releases Packages Wiki Activity

Auto merge of #13649 - ZZzzaaKK:master, r=lnicola

Browse source 
Improve grammar of architecture.md

Corrects a few grammar mistakes I found while reading the documentation 😄
This commit is contained in:
bors 2022-11-20 18:31:50 +00:00
commit 75e1de88f8
1 changed files with 3 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
docs/dev/architecture.md
View file

@ -481,7 +481,7 @@ It is not cheap enough to enable in prod, and this is a bug which should be fixe
rust-analyzer strives to be as configurable as possible while offering reasonable defaults where no configuration exists yet. rust-analyzer strives to be as configurable as possible while offering reasonable defaults where no configuration exists yet.
The rule of thumb is to enable most features by default unless they are buggy or degrade performance too much. The rule of thumb is to enable most features by default unless they are buggy or degrade performance too much.
There will always be features that some people find more annoying than helpful, so giving the users the ability to tweak or disable these is a big part of offering a good user experience. There will always be features that some people find more annoying than helpful, so giving the users the ability to tweak or disable these is a big part of offering a good user experience.
Enabling them by default is a matter of discoverability, as many users end up don't know about some features even though they are presented in the manual. Enabling them by default is a matter of discoverability, as many users don't know about some features even though they are presented in the manual.
Mind the code--architecture gap: at the moment, we are using fewer feature flags than we really should. Mind the code--architecture gap: at the moment, we are using fewer feature flags than we really should.
### Serialization ### Serialization
@ -492,8 +492,8 @@ If a type is serializable, then it is a part of some IPC boundary.
You often don't control the other side of this boundary, so changing serializable types is hard. You often don't control the other side of this boundary, so changing serializable types is hard.
For this reason, the types in `ide`, `base_db` and below are not serializable by design. For this reason, the types in `ide`, `base_db` and below are not serializable by design.
If such types need to cross an IPC boundary, then the client of rust-analyzer needs to provide custom, client-specific serialization format. If such types need to cross an IPC boundary, then the client of rust-analyzer needs to provide a custom, client-specific serialization format.
This isolates backwards compatibility and migration concerns to a specific client. This isolates backwards compatibility and migration concerns to a specific client.
For example, `rust-project.json` is it's own format -- it doesn't include `CrateGraph` as is. For example, `rust-project.json` is its own format -- it doesn't include `CrateGraph` as is.
Instead, it creates a `CrateGraph` by calling appropriate constructing functions. Instead, it creates a `CrateGraph` by calling appropriate constructing functions.