mirror of
https://github.com/rust-lang/rust-analyzer
synced 2025-01-12 05:08:52 +00:00
Unresolved questions
This commit is contained in:
parent
2c74af7ddc
commit
268cb2a04e
1 changed files with 27 additions and 5 deletions
32
rfc.md
32
rfc.md
|
@ -394,20 +394,42 @@ plan is suggested:
|
|||
experiemt on crates.io. However, actually using it in the compiler
|
||||
and other tools would require massive refactorings.
|
||||
|
||||
- Proposed syntax tree requires to keep the original source code
|
||||
available, which might increase memory usage of the
|
||||
compiler. However, it should be possible to throw the original tree
|
||||
and source code away after conversion to HIR.
|
||||
|
||||
# Rationale and alternatives
|
||||
[alternatives]: #alternatives
|
||||
|
||||
- Incrementally add more information about source code to the current AST.
|
||||
- Move the current libsyntax to crates.io as is.
|
||||
- Incrementally add more information about source code to the current
|
||||
AST.
|
||||
|
||||
- Move the current libsyntax to crates.io as is. In the past, there
|
||||
were several failed attempts to do that.
|
||||
|
||||
- Explore alternative representations for the parse tree.
|
||||
- Use parser generator instead of hand written parser.
|
||||
|
||||
- Use parser generator instead of hand written parser. Using the
|
||||
parser from libsyntax directly would be easier, and hand-written
|
||||
LL-style parsers usually have much better error recovery than
|
||||
generated LR-style ones.
|
||||
|
||||
# Unresolved questions
|
||||
[unresolved]: #unresolved-questions
|
||||
|
||||
- Is it at all possible to represent Rust parser as a pure function of
|
||||
the source code?
|
||||
the source code? It seems like the answer is yes, because the
|
||||
language and especially macros were cleverly designed with this
|
||||
use-case in mind.
|
||||
|
||||
|
||||
- Is it possible to implement macro expansion using the proposed
|
||||
framework?
|
||||
framework? This is the main question of this RFC. The proposed
|
||||
solution of synthesizing source code on the fly seems workable: it's
|
||||
not that different from the current implementation, which
|
||||
synthesizes token trees.
|
||||
|
||||
|
||||
- How to actually phase out current libsyntax, if libsyntax2.0 turns
|
||||
out to be a success?
|
||||
|
|
Loading…
Reference in a new issue