diff options
-rw-r--r-- | rfc.md | 32 |
1 files changed, 27 insertions, 5 deletions
@@ -393,21 +393,43 @@ plan is suggested: | |||
393 | - No harm will be done as long as the new libsyntax exists as an | 393 | - No harm will be done as long as the new libsyntax exists as an |
394 | experiemt on crates.io. However, actually using it in the compiler | 394 | experiemt on crates.io. However, actually using it in the compiler |
395 | and other tools would require massive refactorings. | 395 | and other tools would require massive refactorings. |
396 | |||
397 | - Proposed syntax tree requires to keep the original source code | ||
398 | available, which might increase memory usage of the | ||
399 | compiler. However, it should be possible to throw the original tree | ||
400 | and source code away after conversion to HIR. | ||
396 | 401 | ||
397 | # Rationale and alternatives | 402 | # Rationale and alternatives |
398 | [alternatives]: #alternatives | 403 | [alternatives]: #alternatives |
399 | 404 | ||
400 | - Incrementally add more information about source code to the current AST. | 405 | - Incrementally add more information about source code to the current |
401 | - Move the current libsyntax to crates.io as is. | 406 | AST. |
407 | |||
408 | - Move the current libsyntax to crates.io as is. In the past, there | ||
409 | were several failed attempts to do that. | ||
410 | |||
402 | - Explore alternative representations for the parse tree. | 411 | - Explore alternative representations for the parse tree. |
403 | - Use parser generator instead of hand written parser. | 412 | |
413 | - Use parser generator instead of hand written parser. Using the | ||
414 | parser from libsyntax directly would be easier, and hand-written | ||
415 | LL-style parsers usually have much better error recovery than | ||
416 | generated LR-style ones. | ||
404 | 417 | ||
405 | # Unresolved questions | 418 | # Unresolved questions |
406 | [unresolved]: #unresolved-questions | 419 | [unresolved]: #unresolved-questions |
407 | 420 | ||
408 | - Is it at all possible to represent Rust parser as a pure function of | 421 | - Is it at all possible to represent Rust parser as a pure function of |
409 | the source code? | 422 | the source code? It seems like the answer is yes, because the |
423 | language and especially macros were cleverly designed with this | ||
424 | use-case in mind. | ||
425 | |||
426 | |||
410 | - Is it possible to implement macro expansion using the proposed | 427 | - Is it possible to implement macro expansion using the proposed |
411 | framework? | 428 | framework? This is the main question of this RFC. The proposed |
429 | solution of synthesizing source code on the fly seems workable: it's | ||
430 | not that different from the current implementation, which | ||
431 | synthesizes token trees. | ||
432 | |||
433 | |||
412 | - How to actually phase out current libsyntax, if libsyntax2.0 turns | 434 | - How to actually phase out current libsyntax, if libsyntax2.0 turns |
413 | out to be a success? | 435 | out to be a success? |