diff options
-rw-r--r-- | docs/dev/ROADMAP.md | 77 |
1 files changed, 0 insertions, 77 deletions
diff --git a/docs/dev/ROADMAP.md b/docs/dev/ROADMAP.md deleted file mode 100644 index 3856ebc5b..000000000 --- a/docs/dev/ROADMAP.md +++ /dev/null | |||
@@ -1,77 +0,0 @@ | |||
1 | # Rust Analyzer Roadmap 01 | ||
2 | |||
3 | Written on 2018-11-06, extends approximately to February 2019. | ||
4 | After that, we should coordinate with the compiler/rls developers to align goals and share code and experience. | ||
5 | |||
6 | |||
7 | # Overall Goals | ||
8 | |||
9 | The mission is: | ||
10 | * Provide an excellent "code analyzed as you type" IDE experience for the Rust language, | ||
11 | * Implement the bulk of the features in Rust itself. | ||
12 | |||
13 | |||
14 | High-level architecture constraints: | ||
15 | * Long-term, replace the current rustc frontend. | ||
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. | ||
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. | ||
20 | |||
21 | |||
22 | # Current Goals | ||
23 | |||
24 | Ideally, we would be coordinating with the compiler/rls teams, but they are busy working on making Rust 2018 at the moment. | ||
25 | The sync-up point will happen some time after the edition, probably early 2019. | ||
26 | In the meantime, the goal is to **experiment**, specifically, to figure out how a from-scratch written RLS might look like. | ||
27 | |||
28 | |||
29 | ## Data Storage and Protocol implementation | ||
30 | |||
31 | The fundamental part of any architecture is who owns which data, how the data is mutated and how the data is exposed to user. | ||
32 | For 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 | |||
34 | Modification to source files is mostly driven by the language client, but we also should support watching the file system. The current | ||
35 | file watching implementation is a stub. | ||
36 | |||
37 | **Action Item:** implement reliable file watching service. | ||
38 | |||
39 | We also should extract LSP bits as a reusable library. There's already `gen_lsp_server`, but it is pretty limited. | ||
40 | |||
41 | **Action Item:** try using `gen_lsp_server` in more than one language server, for example for TOML and Nix. | ||
42 | |||
43 | The ideal architecture for `gen_lsp_server` is still unclear. I'd rather avoid futures: they bring significant runtime complexity | ||
44 | (call stacks become insane) and the performance benefits are negligible for our use case (one thread per request is perfectly OK given | ||
45 | the low amount of requests a language server receives). The current interface is based on crossbeam-channel, but it's not clear | ||
46 | if that is the best choice. | ||
47 | |||
48 | |||
49 | ## Low-effort, high payoff features | ||
50 | |||
51 | Implementing 20% of type inference will give use 80% of completion. | ||
52 | Thus it makes sense to partially implement name resolution, type inference and trait matching, even though there is a chance that | ||
53 | this code is replaced later on when we integrate with the compiler | ||
54 | |||
55 | Specifically, we need to: | ||
56 | |||
57 | * **Action Item:** implement path resolution, so that we get completion in imports and such. | ||
58 | * **Action Item:** implement simple type inference, so that we get completion for inherent methods. | ||
59 | * **Action Item:** implement nicer completion infrastructure, so that we have icons, snippets, doc comments, after insert callbacks, ... | ||
60 | |||
61 | |||
62 | ## Dragons to kill | ||
63 | |||
64 | To make experiments most effective, we should try to prototype solutions for the hardest problems. | ||
65 | In the case of Rust, the two hardest problems are: | ||
66 | * Conditional compilation and source/model mismatch. | ||
67 | A single source file might correspond to several entities in the semantic model. | ||
68 | For example, different cfg flags produce effectively different crates from the same source. | ||
69 | * Macros are intertwined with name resolution in a single fix-point iteration algorithm. | ||
70 | This is just plain hard to implement, but also interacts poorly with on-demand. | ||
71 | |||
72 | |||
73 | For 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. | ||
74 | The **action item** here is basically "write code, see what works, keep high-level picture in mind". | ||
75 | |||
76 | For 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. | ||
77 | Again, the **action item** is to write the code and see what works. Salsa itself uses macros heavily, so it should be a great test. | ||