aboutsummaryrefslogtreecommitdiff
path: root/docs/dev
diff options
context:
space:
mode:
authorAleksey Kladov <[email protected]>2020-02-18 11:33:16 +0000
committerAleksey Kladov <[email protected]>2020-02-18 11:33:16 +0000
commitc0fa5e2246457df10e92c2e11c971f2f40921793 (patch)
tree323d890c830b14c222113fa8617070c3b1fde3d2 /docs/dev
parent4d307ff8024c8d2d533bc3ab7aac1d63ca5c5977 (diff)
Rename the binary to rust-analyzer
Diffstat (limited to 'docs/dev')
-rw-r--r--docs/dev/README.md18
-rw-r--r--docs/dev/architecture.md6
-rw-r--r--docs/dev/debugging.md16
3 files changed, 20 insertions, 20 deletions
diff --git a/docs/dev/README.md b/docs/dev/README.md
index ba24524f2..9da2eb014 100644
--- a/docs/dev/README.md
+++ b/docs/dev/README.md
@@ -80,7 +80,7 @@ In general, I use one of the following workflows for fixing bugs and
80implementing features. 80implementing features.
81 81
82If the problem concerns only internal parts of rust-analyzer (ie, I don't need 82If the problem concerns only internal parts of rust-analyzer (ie, I don't need
83to touch `ra_lsp_server` crate or typescript code), there is a unit-test for it. 83to touch `rust-analyzer` crate or typescript code), there is a unit-test for it.
84So, I use **Rust Analyzer: Run** action in VS Code to run this single test, and 84So, I use **Rust Analyzer: Run** action in VS Code to run this single test, and
85then just do printf-driven development/debugging. As a sanity check after I'm 85then just do printf-driven development/debugging. As a sanity check after I'm
86done, I use `cargo xtask install --server` and **Reload Window** action in VS 86done, I use `cargo xtask install --server` and **Reload Window** action in VS
@@ -88,17 +88,17 @@ Code to sanity check that the thing works as I expect.
88 88
89If the problem concerns only the VS Code extension, I use **Run Extension** 89If the problem concerns only the VS Code extension, I use **Run Extension**
90launch configuration from `launch.json`. Notably, this uses the usual 90launch configuration from `launch.json`. Notably, this uses the usual
91`ra_lsp_server` binary from `PATH`. For this it is important to have the following 91`rust-analyzer` binary from `PATH`. For this it is important to have the following
92in `setting.json` file: 92in `setting.json` file:
93```json 93```json
94{ 94{
95 "rust-analyzer.raLspServerPath": "ra_lsp_server" 95 "rust-analyzer.raLspServerPath": "rust-analyzer"
96} 96}
97``` 97```
98After I am done with the fix, I use `cargo 98After I am done with the fix, I use `cargo
99xtask install --client-code` to try the new extension for real. 99xtask install --client-code` to try the new extension for real.
100 100
101If I need to fix something in the `ra_lsp_server` crate, I feel sad because it's 101If I need to fix something in the `rust-analyzer` crate, I feel sad because it's
102on the boundary between the two processes, and working there is slow. I usually 102on the boundary between the two processes, and working there is slow. I usually
103just `cargo xtask install --server` and poke changes from my live environment. 103just `cargo xtask install --server` and poke changes from my live environment.
104Note that this uses `--release`, which is usually faster overall, because 104Note that this uses `--release`, which is usually faster overall, because
@@ -113,7 +113,7 @@ communication, and `print!` would break it.
113If I need to fix something simultaneously in the server and in the client, I 113If I need to fix something simultaneously in the server and in the client, I
114feel even more sad. I don't have a specific workflow for this case. 114feel even more sad. I don't have a specific workflow for this case.
115 115
116Additionally, I use `cargo run --release -p ra_lsp_server -- analysis-stats 116Additionally, I use `cargo run --release -p rust-analyzer -- analysis-stats
117path/to/some/rust/crate` to run a batch analysis. This is primarily useful for 117path/to/some/rust/crate` to run a batch analysis. This is primarily useful for
118performance optimizations, or for bug minimization. 118performance optimizations, or for bug minimization.
119 119
@@ -148,7 +148,7 @@ There's also two VS Code commands which might be of interest:
148* `Rust Analyzer: Status` shows some memory-usage statistics. To take full 148* `Rust Analyzer: Status` shows some memory-usage statistics. To take full
149 advantage of it, you need to compile rust-analyzer with jemalloc support: 149 advantage of it, you need to compile rust-analyzer with jemalloc support:
150 ``` 150 ```
151 $ cargo install --path crates/ra_lsp_server --force --features jemalloc 151 $ cargo install --path crates/rust-analyzer --force --features jemalloc
152 ``` 152 ```
153 153
154 There's an alias for this: `cargo xtask install --server --jemalloc`. 154 There's an alias for this: `cargo xtask install --server --jemalloc`.
@@ -170,12 +170,12 @@ In particular, I have `export RA_PROFILE='*>10'` in my shell profile.
170To measure time for from-scratch analysis, use something like this: 170To measure time for from-scratch analysis, use something like this:
171 171
172``` 172```
173$ cargo run --release -p ra_lsp_server -- analysis-stats ../chalk/ 173$ cargo run --release -p rust-analyzer -- analysis-stats ../chalk/
174``` 174```
175 175
176For measuring time of incremental analysis, use either of these: 176For measuring time of incremental analysis, use either of these:
177 177
178``` 178```
179$ cargo run --release -p ra_lsp_server -- analysis-bench ../chalk/ --highlight ../chalk/chalk-engine/src/logic.rs 179$ cargo run --release -p rust-analyzer -- analysis-bench ../chalk/ --highlight ../chalk/chalk-engine/src/logic.rs
180$ cargo run --release -p ra_lsp_server -- analysis-bench ../chalk/ --complete ../chalk/chalk-engine/src/logic.rs:94:0 180$ cargo run --release -p rust-analyzer -- analysis-bench ../chalk/ --complete ../chalk/chalk-engine/src/logic.rs:94:0
181``` 181```
diff --git a/docs/dev/architecture.md b/docs/dev/architecture.md
index 41c3909f7..0343b6c81 100644
--- a/docs/dev/architecture.md
+++ b/docs/dev/architecture.md
@@ -134,7 +134,7 @@ APIs in this crate are IDE centric: they take text offsets as input and produce
134offsets and strings as output. This works on top of rich code model powered by 134offsets and strings as output. This works on top of rich code model powered by
135`hir`. 135`hir`.
136 136
137### `crates/ra_lsp_server` 137### `crates/rust-analyzer`
138 138
139An LSP implementation which wraps `ra_ide` into a language server protocol. 139An LSP implementation which wraps `ra_ide` into a language server protocol.
140 140
@@ -153,7 +153,7 @@ Rust Analyzer has three interesting [systems
153boundaries](https://www.tedinski.com/2018/04/10/making-tests-a-positive-influence-on-design.html) 153boundaries](https://www.tedinski.com/2018/04/10/making-tests-a-positive-influence-on-design.html)
154to concentrate tests on. 154to concentrate tests on.
155 155
156The outermost boundary is the `ra_lsp_server` crate, which defines an LSP 156The outermost boundary is the `rust-analyzer` crate, which defines an LSP
157interface in terms of stdio. We do integration testing of this component, by 157interface in terms of stdio. We do integration testing of this component, by
158feeding it with a stream of LSP requests and checking responses. These tests are 158feeding it with a stream of LSP requests and checking responses. These tests are
159known as "heavy", because they interact with Cargo and read real files from 159known as "heavy", because they interact with Cargo and read real files from
@@ -162,7 +162,7 @@ in a statically typed language, it's hard to make an error in the protocol
162itself if messages are themselves typed. 162itself if messages are themselves typed.
163 163
164The middle, and most important, boundary is `ra_ide`. Unlike 164The middle, and most important, boundary is `ra_ide`. Unlike
165`ra_lsp_server`, which exposes API, `ide` uses Rust API and is intended to 165`rust-analyzer`, which exposes API, `ide` uses Rust API and is intended to
166use by various tools. Typical test creates an `AnalysisHost`, calls some 166use by various tools. Typical test creates an `AnalysisHost`, calls some
167`Analysis` functions and compares the results against expectation. 167`Analysis` functions and compares the results against expectation.
168 168
diff --git a/docs/dev/debugging.md b/docs/dev/debugging.md
index e6b082156..bece6a572 100644
--- a/docs/dev/debugging.md
+++ b/docs/dev/debugging.md
@@ -22,8 +22,8 @@ where **only** the `rust-analyzer` extension being debugged is enabled.
22 22
23## Debug TypeScript VSCode extension 23## Debug TypeScript VSCode extension
24 24
25- `Run Extension` - runs the extension with the globally installed `ra_lsp_server` binary. 25- `Run Extension` - runs the extension with the globally installed `rust-analyzer` binary.
26- `Run Extension (Dev Server)` - runs extension with the locally built LSP server (`target/debug/ra_lsp_server`). 26- `Run Extension (Dev Server)` - runs extension with the locally built LSP server (`target/debug/rust-analyzer`).
27 27
28TypeScript debugging is configured to watch your source edits and recompile. 28TypeScript debugging is configured to watch your source edits and recompile.
29To apply changes to an already running debug process press <kbd>Ctrl+Shift+P</kbd> and run the following command in your `[Extension Development Host]` 29To apply changes to an already running debug process press <kbd>Ctrl+Shift+P</kbd> and run the following command in your `[Extension Development Host]`
@@ -47,13 +47,13 @@ To apply changes to an already running debug process press <kbd>Ctrl+Shift+P</kb
47 debug = 2 47 debug = 2
48 ``` 48 ```
49 49
50- Select `Run Extension (Dev Server)` to run your locally built `target/debug/ra_lsp_server`. 50- Select `Run Extension (Dev Server)` to run your locally built `target/debug/rust-analyzer`.
51 51
52- In the original VSCode window once again select the `Attach To Server` debug configuration. 52- In the original VSCode window once again select the `Attach To Server` debug configuration.
53 53
54- A list of running processes should appear. Select the `ra_lsp_server` from this repo. 54- A list of running processes should appear. Select the `rust-analyzer` from this repo.
55 55
56- Navigate to `crates/ra_lsp_server/src/main_loop.rs` and add a breakpoint to the `on_task` function. 56- Navigate to `crates/rust-analyzer/src/main_loop.rs` and add a breakpoint to the `on_task` function.
57 57
58- Go back to the `[Extension Development Host]` instance and hover over a Rust variable and your breakpoint should hit. 58- Go back to the `[Extension Development Host]` instance and hover over a Rust variable and your breakpoint should hit.
59 59
@@ -64,15 +64,15 @@ To apply changes to an already running debug process press <kbd>Ctrl+Shift+P</kb
64 64
65## Troubleshooting 65## Troubleshooting
66 66
67### Can't find the `ra_lsp_server` process 67### Can't find the `rust-analyzer` process
68 68
69It could be a case of just jumping the gun. 69It could be a case of just jumping the gun.
70 70
71The `ra_lsp_server` is only started once the `onLanguage:rust` activation. 71The `rust-analyzer` is only started once the `onLanguage:rust` activation.
72 72
73Make sure you open a rust file in the `[Extension Development Host]` and try again. 73Make sure you open a rust file in the `[Extension Development Host]` and try again.
74 74
75### Can't connect to `ra_lsp_server` 75### Can't connect to `rust-analyzer`
76 76
77Make sure you have run `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope`. 77Make sure you have run `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope`.
78 78