Mirrors/rust-analyzer
2
0
Fork 0
mirror of https://github.com/rust-lang/rust-analyzer synced 2024-12-27 05:23:24 +00:00
Code Issues Projects Releases Packages Wiki Activity

Merge #9081

Browse source 
9081: minor: expand docs a tiny bit r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
This commit is contained in:
bors[bot] 2021-05-31 14:28:03 +00:00 committed by GitHub
commit 70e347332d
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
docs/dev/architecture.md
View file

@ -146,6 +146,8 @@ Reading the docs of the `base_db::input` module should be useful: everything els
**Architecture Invariant:** particularities of the build system are *not* the part of the ground state. **Architecture Invariant:** particularities of the build system are *not* the part of the ground state.
In particular, `base_db` knows nothing about cargo. In particular, `base_db` knows nothing about cargo.
For example, `cfg` flags are a part of `base_db`, but `feature`s are not.
A `foo` feature is a Cargo-level concept, which is lowered by Cargo to `--cfg feature=foo` argument on the command line.
The `CrateGraph` structure is used to represent the dependencies between the crates abstractly. The `CrateGraph` structure is used to represent the dependencies between the crates abstractly.
**Architecture Invariant:** `base_db` doesn't know about file system and file paths. **Architecture Invariant:** `base_db` doesn't know about file system and file paths.
@ -452,3 +454,4 @@ 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.
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.
Mind the code--architecture gap: at the moment, we are using fewer feature flags than we really should.