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 @@
 # Rust Analyzer Roadmap 01
 Written on 2018-11-06, extends approximately to February 2019.
-After, we should coordinate with rustc/RLS developers to align goals and share code and experience.
+After that, we should coordinate with the compiler/rls developers to align goals and share code and experience.
 # Overall Goals
 The mission is:
-  * provide an excellent "code analyzed as you type" IDE experience for the Rust language,
+  * Provide an excellent "code analyzed as you type" IDE experience for the Rust language,
-  * implementing the bulk of the features in Rust itself.
+  * Implement the bulk of the features in Rust itself.
 High-level architecture constraints:
-  * Aim, long-term, to use the single code base with rustc.
+  * Long-term, replace the current rustc frontend.
-    It's *obvious* then the code should be shared, but OTOH, all great IDEs started as from-scratch rewrites.
+    It's *obvious* that the code should be shared, but OTOH, all great IDEs started as from-scratch rewrites.
  * Don't hard-code a particular protocol or mode of operation.
    Produce a library which could be used for implementing an LSP server, or for in-process embedding.
  * 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:
 # Current Goals
-We really should be coordinating with compiler/rls teams, but they are busy working on making Rust 2018 at the moment.
+Ideally, we would be coordinating with the compiler/rls teams, but they are busy working on making Rust 2018 at the moment.
-The sync-up point will happen some time after the edition, probably early next year.
+The sync-up point will happen some time after the edition, probably early 2019.
-In the mean time, the goal is to **experiment**, specifically, to figure out how a from-scratch written RLS might look like.
+In the meantime, the goal is to **experiment**, specifically, to figure out how a from-scratch written RLS might look like.
 ## Data Storage and Protocol implementation
-The fundamental part of any architecture is who owned what data, how the data is mutated and how the data is exposed to user.
+The fundamental part of any architecture is who owns which data, how the data is mutated and how the data is exposed to user.
-For storage we use the [salsa](http://github.com/salsa-rs/salsa) library, and the model already seems solid.
+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.
-Most of modification is driven by the language client, but we also should support watching the file system, current implementation is a stub.
+Modification to source files is mostly driven by the language client, but we also should support watching the file system. The current
+file watching implementation is a stub.
 **Action Item:** implement reliable file watching service.
@@ -39,27 +40,29 @@ We also should extract LSP bits as a reusable library. There's already `gen_lsp_
 **Action Item:** try using `gen_lsp_server` in more than one language server, for example for TOML and Nix.
-Note that it is unclear what shape is ideal for `gen_lsp_server`.
+The ideal architecture for `gen_lsp_server` is still unclear. I'd rather avoid futures: they bring significant runtime complexity
-I'd rather avoid futures: they bring significant runtime complexity (call stacks become insane), but we don't have c10k problem to solve.
+(call stacks become insane) and the performance benefits are negligible for our use case (one thread per request is perfectly OK given
-Current interface is based on crossbeam-channel, but it's not clear if that is the best choice.
+the low amount of requests a language server receives). The current interface is based on crossbeam-channel, but it's not clear
+if that is the best choice.
 ## Low-effort, high payoff features
 Implementing 20% of type inference will give use 80% of completion.
-Thus 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.
+Thus it makes sense to partially implement name resolution, type inference and trait matching, even though there is a chance that
+this code is replaced later on when we integrate with the compiler
 Specifically, we need to:
-**Action Item:** implement path resolution, so that we get completion in imports and such.
+* **Action Item:** implement path resolution, so that we get completion in imports and such.
-**Action Item:** implement simple type inference, so that we get completion for inherent methods.
+* **Action Item:** implement simple type inference, so that we get completion for inherent methods.
-**Action Item:** implement nicer completion infrastructure, so that we have icons, snippets, doc comments, after insert callbacks, ...
+* **Action Item:** implement nicer completion infrastructure, so that we have icons, snippets, doc comments, after insert callbacks, ...
 ## Dragons to kill
 To make experiments most effective, we should try to prototype solutions for the hardest problems.
-In case of Rust, the two hardest problems are:
+In the case of Rust, the two hardest problems are:
  * Conditional compilation and source/model mismatch.
    A single source file might correspond to several entities in the semantic model.
    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:
 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.
-The action item here is basically "write code, see what works, keep high-level picture in mind".
+The **action item** here is basically "write code, see what works, keep high-level picture in mind".
-For the second bullet point there's hope that salsa with its deep memorization will give us fast enough solution even without full on-demand.
+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.
-Again, action item is to write the code and see what works. Salsa itself uses macros heavily, so it should be a great test.
+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.

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
3	Written on 2018-11-06, extends approximately to February 2019.	3	Written on 2018-11-06, extends approximately to February 2019.
4	After, we should coordinate with rustc/RLS developers to align goals and share code and experience.	4	After 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
9	The mission is:	9	The 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
14	High-level architecture constraints:	14	High-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
24	We really should be coordinating with compiler/rls teams, but they are busy working on making Rust 2018 at the moment.	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 next year.	25	The sync-up point will happen some time after the edition, probably early 2019.
26	In the mean time, the goal is to experiment, specifically, to figure out how a from-scratch written RLS might look like.	26	In 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
31	The fundamental part of any architecture is who owned what data, how the data is mutated and how the data is exposed to user.	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, and the model already seems solid.	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		33
34	Most of modification is driven by the language client, but we also should support watching the file system, current implementation is a stub.	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.
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
42	Note that it is unclear what shape is ideal for `gen_lsp_server`.	43	The ideal architecture for `gen_lsp_server` is still unclear. I'd rather avoid futures: they bring significant runtime complexity
43	I'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
44	Current interface is based on crossbeam-channel, but it's not clear if that is the best choice.	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.
45		47
46		48
47	## Low-effort, high payoff features	49	## Low-effort, high payoff features
48		50
49	Implementing 20% of type inference will give use 80% of completion.	51	Implementing 20% of type inference will give use 80% of completion.
50	Thus 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.	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
51		54
52	Specifically, we need to:	55	Specifically, 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
61	To make experiments most effective, we should try to prototype solutions for the hardest problems.	64	To make experiments most effective, we should try to prototype solutions for the hardest problems.
62	In case of Rust, the two hardest problems are:	65	In 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
70	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.	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.
71	The action item here is basically "write code, see what works, keep high-level picture in mind".	74	The action item here is basically "write code, see what works, keep high-level picture in mind".
72		75
73	For the second bullet point there's hope that salsa with its deep memorization will give us fast enough solution even without full on-demand.	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.
74	Again, action item is to write the code and see what works. Salsa itself uses macros heavily, so it should be a great test.	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.