aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--ROADMAP.md47
1 files changed, 25 insertions, 22 deletions
diff --git a/ROADMAP.md b/ROADMAP.md
index 05fad38ec..951a092b4 100644
--- a/ROADMAP.md
+++ b/ROADMAP.md
@@ -1,19 +1,19 @@
1# Rust Analyzer Roadmap 01 1# Rust Analyzer Roadmap 01
2 2
3Written on 2018-11-06, extends approximately to February 2019. 3Written on 2018-11-06, extends approximately to February 2019.
4After, we should coordinate with rustc/RLS developers to align goals and share code and experience. 4After that, we should coordinate with the compiler/rls developers to align goals and share code and experience.
5 5
6 6
7# Overall Goals 7# Overall Goals
8 8
9The mission is: 9The mission is:
10 * provide an excellent "code analyzed as you type" IDE experience for the Rust language, 10 * Provide an excellent "code analyzed as you type" IDE experience for the Rust language,
11 * implementing the bulk of the features in Rust itself. 11 * Implement the bulk of the features in Rust itself.
12 12
13 13
14High-level architecture constraints: 14High-level architecture constraints:
15 * Aim, long-term, to use the single code base with rustc. 15 * Long-term, replace the current rustc frontend.
16 It's *obvious* then the code should be shared, but OTOH, all great IDEs started as from-scratch rewrites. 16 It's *obvious* that the code should be shared, but OTOH, all great IDEs started as from-scratch rewrites.
17 * Don't hard-code a particular protocol or mode of operation. 17 * Don't hard-code a particular protocol or mode of operation.
18 Produce a library which could be used for implementing an LSP server, or for in-process embedding. 18 Produce a library which could be used for implementing an LSP server, or for in-process embedding.
19 * As long as possible, stick with stable Rust (NB: we currently use beta for 2018 edition and salsa). 19 * As long as possible, stick with stable Rust (NB: we currently use beta for 2018 edition and salsa).
@@ -21,17 +21,18 @@ High-level architecture constraints:
21 21
22# Current Goals 22# Current Goals
23 23
24We really should be coordinating with compiler/rls teams, but they are busy working on making Rust 2018 at the moment. 24Ideally, we would be coordinating with the compiler/rls teams, but they are busy working on making Rust 2018 at the moment.
25The sync-up point will happen some time after the edition, probably early next year. 25The sync-up point will happen some time after the edition, probably early 2019.
26In the mean time, the goal is to **experiment**, specifically, to figure out how a from-scratch written RLS might look like. 26In the meantime, the goal is to **experiment**, specifically, to figure out how a from-scratch written RLS might look like.
27 27
28 28
29## Data Storage and Protocol implementation 29## Data Storage and Protocol implementation
30 30
31The fundamental part of any architecture is who owned what data, how the data is mutated and how the data is exposed to user. 31The fundamental part of any architecture is who owns which data, how the data is mutated and how the data is exposed to user.
32For storage we use the [salsa](http://github.com/salsa-rs/salsa) library, and the model already seems solid. 32For storage we use the [salsa](http://github.com/salsa-rs/salsa) library, which provides a solid model that seems to be the way to go.
33 33
34Most of modification is driven by the language client, but we also should support watching the file system, current implementation is a stub. 34Modification to source files is mostly driven by the language client, but we also should support watching the file system. The current
35file watching implementation is a stub.
35 36
36**Action Item:** implement reliable file watching service. 37**Action Item:** implement reliable file watching service.
37 38
@@ -39,27 +40,29 @@ We also should extract LSP bits as a reusable library. There's already `gen_lsp_
39 40
40**Action Item:** try using `gen_lsp_server` in more than one language server, for example for TOML and Nix. 41**Action Item:** try using `gen_lsp_server` in more than one language server, for example for TOML and Nix.
41 42
42Note that it is unclear what shape is ideal for `gen_lsp_server`. 43The ideal architecture for `gen_lsp_server` is still unclear. I'd rather avoid futures: they bring significant runtime complexity
43I'd rather avoid futures: they bring significant runtime complexity (call stacks become insane), but we don't have c10k problem to solve. 44(call stacks become insane) and the performance benefits are negligible for our use case (one thread per request is perfectly OK given
44Current interface is based on crossbeam-channel, but it's not clear if that is the best choice. 45the low amount of requests a language server receives). The current interface is based on crossbeam-channel, but it's not clear
46if that is the best choice.
45 47
46 48
47## Low-effort, high payoff features 49## Low-effort, high payoff features
48 50
49Implementing 20% of type inference will give use 80% of completion. 51Implementing 20% of type inference will give use 80% of completion.
50Thus it makes sense to try to get some name resolution, type inference and trait matching implemented, even if all this code will be removed when we start sharing code with compiler. 52Thus it makes sense to partially implement name resolution, type inference and trait matching, even though there is a chance that
53this code is replaced later on when we integrate with the compiler
51 54
52Specifically, we need to: 55Specifically, we need to:
53 56
54**Action Item:** implement path resolution, so that we get completion in imports and such. 57* **Action Item:** implement path resolution, so that we get completion in imports and such.
55**Action Item:** implement simple type inference, so that we get completion for inherent methods. 58* **Action Item:** implement simple type inference, so that we get completion for inherent methods.
56**Action Item:** implement nicer completion infrastructure, so that we have icons, snippets, doc comments, after insert callbacks, ... 59* **Action Item:** implement nicer completion infrastructure, so that we have icons, snippets, doc comments, after insert callbacks, ...
57 60
58 61
59## Dragons to kill 62## Dragons to kill
60 63
61To make experiments most effective, we should try to prototype solutions for the hardest problems. 64To make experiments most effective, we should try to prototype solutions for the hardest problems.
62In case of Rust, the two hardest problems are: 65In the case of Rust, the two hardest problems are:
63 * Conditional compilation and source/model mismatch. 66 * Conditional compilation and source/model mismatch.
64 A single source file might correspond to several entities in the semantic model. 67 A single source file might correspond to several entities in the semantic model.
65 For example, different cfg flags produce effectively different crates from the same source. 68 For example, different cfg flags produce effectively different crates from the same source.
@@ -68,7 +71,7 @@ In case of Rust, the two hardest problems are:
68 71
69 72
70For the first bullet point, we need to design descriptors infra and explicit mapping step between sources and semantic model, which is intentionally fuzzy in one direction. 73For the first bullet point, we need to design descriptors infra and explicit mapping step between sources and semantic model, which is intentionally fuzzy in one direction.
71The action item here is basically "write code, see what works, keep high-level picture in mind". 74The **action item** here is basically "write code, see what works, keep high-level picture in mind".
72 75
73For the second bullet point there's hope that salsa with its deep memorization will give us fast enough solution even without full on-demand. 76For the second bullet point, there's hope that salsa with its deep memoization will result in a fast enough solution even without being fully on-demand.
74Again, action item is to write the code and see what works. Salsa itself uses macros heavily, so it should be a great test. 77Again, the **action item** is to write the code and see what works. Salsa itself uses macros heavily, so it should be a great test.