rust/ARCHITECTURE.md

157 lines
6.6 KiB
Markdown
Raw Normal View History

2018-10-10 02:30:41 +08:00
# Architecture
This document describes high-level architecture of rust-analyzer.
If you want to familiarize yourself with the code base, you are just
in the right place!
## Code generation
Some of the components of this repository are generated through automatic
processes. These are outlined below:
2018-10-17 02:09:22 +08:00
- `gen-syntax`: The kinds of tokens are reused in several places, so a generator
2018-10-15 06:14:47 +08:00
is used. We use tera templates to generate the files listed below, based on
the grammar described in [grammar.ron]:
2018-10-10 02:30:41 +08:00
- [ast/generated.rs][ast generated] in `ra_syntax` based on
[ast/generated.tera.rs][ast source]
- [syntax_kinds/generated.rs][syntax_kinds generated] in `ra_syntax` based on
[syntax_kinds/generated.tera.rs][syntax_kinds source]
[tera]: https://tera.netlify.com/
[grammar.ron]: ./crates/ra_syntax/src/grammar.ron
[ast generated]: ./crates/ra_syntax/src/ast/generated.rs
2018-10-15 06:14:47 +08:00
[ast source]: ./crates/ra_syntax/src/ast/generated.rs.tera
2018-10-10 02:30:41 +08:00
[syntax_kinds generated]: ./crates/ra_syntax/src/syntax_kinds/generated.rs
2018-10-15 06:14:47 +08:00
[syntax_kinds source]: ./crates/ra_syntax/src/syntax_kinds/generated.rs.tera
2018-10-10 02:30:41 +08:00
## Code Walk-Through
### `crates/ra_syntax`
Rust syntax tree structure and parser. See
[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
2018-10-15 06:14:47 +08:00
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),
2018-10-10 02:30:41 +08:00
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)
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.
- `grammar.ron` RON description of the grammar, which is used to
2018-10-17 02:09:22 +08:00
generate `syntax_kinds` and `ast` modules, using `cargo gen-syntax` command.
2018-10-10 02:30:41 +08:00
- `algo`: generic tree algorithms, including `walk` for O(1) stack
space tree traversal (this is cool) and `visit` for type-driven
visiting the nodes (this is double plus cool, if you understand how
`Visitor` works, you understand rust-analyzer).
Test for ra_syntax are mostly data-driven: `tests/data/parser` contains a bunch of `.rs`
(test vectors) and `.txt` files with corresponding syntax trees. During testing, we check
`.rs` against `.txt`. If the `.txt` file is missing, it is created (this is how you update
tests). Additionally, running `cargo gen-tests` will walk the grammar module and collect
all `//test test_name` comments into files inside `tests/data` directory.
See [#93](https://github.com/rust-analyzer/rust-analyzer/pull/93) for an example PR which
fixes a bug in the grammar.
2018-12-18 04:23:39 +08:00
### `crates/ra_db`
2018-12-10 22:07:07 +08:00
2018-12-18 04:23:39 +08:00
We use [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 interracting with salsa. Crucially, it
defines most of the "input" queries: facts supplied by the client of the analyzer.
2018-10-10 02:30:41 +08:00
2018-12-18 04:23:39 +08:00
### `crates/ra_hir`
2018-10-10 02:30:41 +08:00
2018-12-18 04:23:39 +08:00
HIR provides a high-level "object oriented" acess to Rust code.
2018-10-10 02:30:41 +08:00
2018-12-18 04:23:39 +08:00
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, there relation between
syntax and HIR is many-to-one. The `source_binder` modules is responsible for
guessing a hir for a particular source position.
2018-10-10 02:30:41 +08:00
2018-12-18 04:23:39 +08:00
Underneath, hir works on top of salsa, using a `HirDatabase` trait.
2018-10-10 02:30:41 +08:00
### `crates/ra_analysis`
A stateful library for analyzing many Rust files as they change.
`AnalysisHost` is a mutable entity (clojure's atom) which holds
current state, incorporates changes and handles out `Analysis` --- an
immutable consistent snapshot of world state at a point in time, which
actually powers analysis.
2018-12-18 04:34:07 +08:00
One interesting aspect of analysis is its support for cancelation. 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
database.
2018-10-10 02:30:41 +08:00
### `crates/ra_lsp_server`
An LSP implementation which uses `ra_analysis` for managing state and
`ra_editor` for actually doing useful stuff.
See [#79](https://github.com/rust-analyzer/rust-analyzer/pull/79/) as an
example of PR which adds a new feature to `ra_editor` and exposes it
to `ra_lsp_server`.
2018-12-18 04:23:39 +08:00
### `crates/ra_editor`
All IDE features which can be implemented if you only have access to a
single file. `ra_editor` could be used to enhance editing of Rust code
without the need to fiddle with build-systems, file
synchronization and such.
In a sense, `ra_editor` is just a bunch of pure functions which take a
syntax tree as an input.
The tests for `ra_editor` are `#[cfg(test)] mod tests` unit-tests spread
throughout its modules.
2018-12-10 22:07:07 +08:00
### `crates/gen_lsp_server`
A language server scaffold, exposing a synchronous crossbeam-channel based API.
This crate handles protocol handshaking and parsing messages, while you
control the message dispatch loop yourself.
Run with `RUST_LOG=sync_lsp_server=debug` to see all the messages.
2018-10-10 02:30:41 +08:00
2018-12-10 22:07:07 +08:00
### `crates/ra_cli`
2018-10-10 02:30:41 +08:00
A CLI interface to rust-analyzer.
### `crate/tools`
2018-10-15 06:14:47 +08:00
Custom Cargo tasks used to develop rust-analyzer:
2018-10-10 02:30:41 +08:00
2018-10-17 02:09:22 +08:00
- `cargo gen-syntax` -- generate `ast` and `syntax_kinds`
2018-10-10 02:30:41 +08:00
- `cargo gen-tests` -- collect inline tests from grammar
- `cargo install-code` -- build and install VS Code extension and server
### `editors/code`
VS Code plugin
## Common workflows
2018-10-15 06:14:47 +08:00
To try out VS Code extensions, run `cargo install-code`. This installs both the
2018-10-28 23:33:56 +08:00
`ra_lsp_server` binary and VS Code extension. To install only the binary, use
`cargo install --path crates/ra_lsp_server --force`
2018-10-15 06:14:47 +08:00
To see logs from the language server, set `RUST_LOG=info` env variable. To see
all communication between the server and the client, use
2018-10-10 02:30:41 +08:00
`RUST_LOG=gen_lsp_server=debug` (will print quite a bit of stuff).
To run tests, just `cargo test`.
2018-10-15 06:14:47 +08:00
To work on 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`.
2018-10-10 02:30:41 +08:00