aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAleksey Kladov <[email protected]>2017-12-22 12:31:48 +0000
committerAleksey Kladov <[email protected]>2017-12-22 12:31:48 +0000
commitb878f3b636365aa9af327fea1aebf97d34cc87dd (patch)
treecfbef475f978727eab782ae43e93de4f8539b624
parenta5141fc7520be1e52940c002db53eaf3a2f9e83f (diff)
Start detailed design section
-rw-r--r--rfc.md40
1 files changed, 23 insertions, 17 deletions
diff --git a/rfc.md b/rfc.md
index 0e004670b..9b7c79991 100644
--- a/rfc.md
+++ b/rfc.md
@@ -36,9 +36,7 @@ be `0.1.0`.
36# Motivation 36# Motivation
37[motivation]: #motivation 37[motivation]: #motivation
38 38
39"Reusable software component" part is addressed first "IDE ready part" 39## Reusability
40second.
41
42 40
43In theory, parsing can be a pure function, which takes a `&str` as an 41In theory, parsing can be a pure function, which takes a `&str` as an
44input, and produces a `ParseTree` as an output. 42input, and produces a `ParseTree` as an output.
@@ -69,37 +67,45 @@ files. As a data point, it turned out to be easier to move `rustfmt`
69inside of main `rustc` repository than to move libsyntax outside! 67inside of main `rustc` repository than to move libsyntax outside!
70 68
71 69
70## IDE support
72 71
72There is one big difference in how IDEs and compilers typically treat
73source code.
73 74
75In the compiler, it is convenient to transform the source
76code into Abstract Syntax Tree form, which is independent of the
77surface syntax. For example, it's convenient to discard comments,
78whitespaces and desugar some syntactic constructs in terms of the
79simpler ones.
74 80
81In contrast, for IDEs it is crucial to have a lossless view of the
82source code because, for example, it's important to preserve comments
83during refactorings.
75 84
76 85Currently rustc uses the AST approach, which preserves the source code
86information to some extent by storing spans in the AST.
77 87
78 88
79 89
80# Guide-level explanation 90# Guide-level explanation
81[guide-level-explanation]: #guide-level-explanation 91[guide-level-explanation]: #guide-level-explanation
82 92
83Explain the proposal as if it was already included in the language and you were teaching it to another Rust programmer. That generally means: 93Not applicable.
84 94
85- Introducing new named concepts.
86- Explaining the feature largely in terms of examples.
87- Explaining how Rust programmers should *think* about the feature, and how it should impact the way they use Rust. It should explain the impact as concretely as possible.
88- If applicable, provide sample error messages, deprecation warnings, or migration guidance.
89- If applicable, describe the differences between teaching this to existing Rust programmers and new Rust programmers.
90
91For implementation-oriented RFCs (e.g. for compiler internals), this section should focus on how compiler contributors should think about the change, and give examples of its concrete impact. For policy RFCs, this section should provide an example-driven introduction to the policy, and explain its impact in concrete terms.
92 95
93# Reference-level explanation 96# Reference-level explanation
94[reference-level-explanation]: #reference-level-explanation 97[reference-level-explanation]: #reference-level-explanation
95 98
96This is the technical portion of the RFC. Explain the design in sufficient detail that: 99This section proposes a new syntax tree data structure, which should
100be suitable for both compiler and IDE. It is heavily inspired by [PSI]
101data structure which used in [IntelliJ] based IDEs and in the Kotlin
102compiler.
103
97 104
98- Its interaction with other features is clear. 105[PSI]: http://www.jetbrains.org/intellij/sdk/docs/reference_guide/custom_language_support/implementing_parser_and_psi.html
99- It is reasonably clear how the feature would be implemented. 106[IntelliJ]: https://github.com/JetBrains/intellij-community/
100- Corner cases are dissected by example. 107[Kotlin]: https://kotlinlang.org/
101 108
102The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.
103 109
104# Drawbacks 110# Drawbacks
105[drawbacks]: #drawbacks 111[drawbacks]: #drawbacks