diff options
author | Aleksey Kladov <[email protected]> | 2020-02-18 11:33:16 +0000 |
---|---|---|
committer | Aleksey Kladov <[email protected]> | 2020-02-18 11:33:16 +0000 |
commit | c0fa5e2246457df10e92c2e11c971f2f40921793 (patch) | |
tree | 323d890c830b14c222113fa8617070c3b1fde3d2 /docs/dev | |
parent | 4d307ff8024c8d2d533bc3ab7aac1d63ca5c5977 (diff) |
Rename the binary to rust-analyzer
Diffstat (limited to 'docs/dev')
-rw-r--r-- | docs/dev/README.md | 18 | ||||
-rw-r--r-- | docs/dev/architecture.md | 6 | ||||
-rw-r--r-- | docs/dev/debugging.md | 16 |
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 | |||
80 | implementing features. | 80 | implementing features. |
81 | 81 | ||
82 | If the problem concerns only internal parts of rust-analyzer (ie, I don't need | 82 | If the problem concerns only internal parts of rust-analyzer (ie, I don't need |
83 | to touch `ra_lsp_server` crate or typescript code), there is a unit-test for it. | 83 | to touch `rust-analyzer` crate or typescript code), there is a unit-test for it. |
84 | So, I use **Rust Analyzer: Run** action in VS Code to run this single test, and | 84 | So, I use **Rust Analyzer: Run** action in VS Code to run this single test, and |
85 | then just do printf-driven development/debugging. As a sanity check after I'm | 85 | then just do printf-driven development/debugging. As a sanity check after I'm |
86 | done, I use `cargo xtask install --server` and **Reload Window** action in VS | 86 | done, 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 | ||
89 | If the problem concerns only the VS Code extension, I use **Run Extension** | 89 | If the problem concerns only the VS Code extension, I use **Run Extension** |
90 | launch configuration from `launch.json`. Notably, this uses the usual | 90 | launch 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 |
92 | in `setting.json` file: | 92 | in `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 | ``` |
98 | After I am done with the fix, I use `cargo | 98 | After I am done with the fix, I use `cargo |
99 | xtask install --client-code` to try the new extension for real. | 99 | xtask install --client-code` to try the new extension for real. |
100 | 100 | ||
101 | If I need to fix something in the `ra_lsp_server` crate, I feel sad because it's | 101 | If I need to fix something in the `rust-analyzer` crate, I feel sad because it's |
102 | on the boundary between the two processes, and working there is slow. I usually | 102 | on the boundary between the two processes, and working there is slow. I usually |
103 | just `cargo xtask install --server` and poke changes from my live environment. | 103 | just `cargo xtask install --server` and poke changes from my live environment. |
104 | Note that this uses `--release`, which is usually faster overall, because | 104 | Note that this uses `--release`, which is usually faster overall, because |
@@ -113,7 +113,7 @@ communication, and `print!` would break it. | |||
113 | If I need to fix something simultaneously in the server and in the client, I | 113 | If I need to fix something simultaneously in the server and in the client, I |
114 | feel even more sad. I don't have a specific workflow for this case. | 114 | feel even more sad. I don't have a specific workflow for this case. |
115 | 115 | ||
116 | Additionally, I use `cargo run --release -p ra_lsp_server -- analysis-stats | 116 | Additionally, I use `cargo run --release -p rust-analyzer -- analysis-stats |
117 | path/to/some/rust/crate` to run a batch analysis. This is primarily useful for | 117 | path/to/some/rust/crate` to run a batch analysis. This is primarily useful for |
118 | performance optimizations, or for bug minimization. | 118 | performance 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. | |||
170 | To measure time for from-scratch analysis, use something like this: | 170 | To 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 | ||
176 | For measuring time of incremental analysis, use either of these: | 176 | For 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 | |||
134 | offsets and strings as output. This works on top of rich code model powered by | 134 | offsets 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 | ||
139 | An LSP implementation which wraps `ra_ide` into a language server protocol. | 139 | An LSP implementation which wraps `ra_ide` into a language server protocol. |
140 | 140 | ||
@@ -153,7 +153,7 @@ Rust Analyzer has three interesting [systems | |||
153 | boundaries](https://www.tedinski.com/2018/04/10/making-tests-a-positive-influence-on-design.html) | 153 | boundaries](https://www.tedinski.com/2018/04/10/making-tests-a-positive-influence-on-design.html) |
154 | to concentrate tests on. | 154 | to concentrate tests on. |
155 | 155 | ||
156 | The outermost boundary is the `ra_lsp_server` crate, which defines an LSP | 156 | The outermost boundary is the `rust-analyzer` crate, which defines an LSP |
157 | interface in terms of stdio. We do integration testing of this component, by | 157 | interface in terms of stdio. We do integration testing of this component, by |
158 | feeding it with a stream of LSP requests and checking responses. These tests are | 158 | feeding it with a stream of LSP requests and checking responses. These tests are |
159 | known as "heavy", because they interact with Cargo and read real files from | 159 | known 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 | |||
162 | itself if messages are themselves typed. | 162 | itself if messages are themselves typed. |
163 | 163 | ||
164 | The middle, and most important, boundary is `ra_ide`. Unlike | 164 | The 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 |
166 | use by various tools. Typical test creates an `AnalysisHost`, calls some | 166 | use 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 | ||
28 | TypeScript debugging is configured to watch your source edits and recompile. | 28 | TypeScript debugging is configured to watch your source edits and recompile. |
29 | To apply changes to an already running debug process press <kbd>Ctrl+Shift+P</kbd> and run the following command in your `[Extension Development Host]` | 29 | To 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 | ||
69 | It could be a case of just jumping the gun. | 69 | It could be a case of just jumping the gun. |
70 | 70 | ||
71 | The `ra_lsp_server` is only started once the `onLanguage:rust` activation. | 71 | The `rust-analyzer` is only started once the `onLanguage:rust` activation. |
72 | 72 | ||
73 | Make sure you open a rust file in the `[Extension Development Host]` and try again. | 73 | Make 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 | ||
77 | Make sure you have run `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope`. | 77 | Make sure you have run `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope`. |
78 | 78 | ||