2018-01-10 21:58:38 +03:00
|
|
|
The project is in its early stages: contributions are welcome and
|
|
|
|
|
would be **very** helpful, but the project is not *yet* optimized for
|
2018-01-28 00:34:16 +03:00
|
|
|
contribution. Moreover, it is doubly experimental, so there's no
|
2018-01-10 21:58:38 +03:00
|
|
|
guarantee that any work here would reach production. That said, here
|
2018-01-28 00:34:16 +03:00
|
|
|
are some areas where contributions would be **especially** welcome:
|
2018-01-10 21:58:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
* Designing internal data structures: RFC only outlines the
|
|
|
|
|
constraints, it's an open question how to satisfy them in the
|
|
|
|
|
optimal way. See `ARCHITECTURE.md` for current design questions.
|
2018-01-28 00:34:16 +03:00
|
|
|
|
2018-09-18 17:40:33 -04:00
|
|
|
* Porting libsyntax parser to rust-analyzer: currently rust-analyzer parses
|
2018-01-10 21:58:38 +03:00
|
|
|
only a tiny subset of Rust. This should be fixed by porting parsing
|
2018-01-28 00:34:16 +03:00
|
|
|
functions from libsyntax one by one. Take a look at the
|
2018-10-04 21:43:58 +01:00
|
|
|
[libsyntax parser]
|
2018-01-28 00:34:16 +03:00
|
|
|
for "what to port" and at the
|
2018-10-04 21:43:58 +01:00
|
|
|
[Kotlin parser]
|
2018-01-28 00:34:16 +03:00
|
|
|
for "how to port".
|
|
|
|
|
|
2018-09-18 17:40:33 -04:00
|
|
|
* Writing validators: by design, rust-analyzer is very lax about the
|
2018-01-10 21:58:38 +03:00
|
|
|
input. For example, the lexer happily accepts unclosed strings. The
|
|
|
|
|
idea is that there should be a higher level visitor, which walks the
|
|
|
|
|
syntax tree after parsing and produces all the warnings. Alas,
|
|
|
|
|
there's no such visitor yet :( Would you like to write one? :)
|
2018-01-28 00:34:16 +03:00
|
|
|
|
2018-01-10 21:58:38 +03:00
|
|
|
* Creating tests: it would be tremendously helpful to read each of
|
2018-09-18 17:40:33 -04:00
|
|
|
libsyntax and rust-analyzer parser functions and crate a small separate
|
2018-01-10 21:58:38 +03:00
|
|
|
test cases to cover each and every edge case.
|
2018-01-28 00:34:16 +03:00
|
|
|
|
2018-09-18 17:40:33 -04:00
|
|
|
* Building stuff with rust-analyzer: it would be really cool to compile
|
|
|
|
|
rust-analyzer to WASM and add *client side* syntax validation to rust
|
2018-01-10 21:58:38 +03:00
|
|
|
playground!
|
|
|
|
|
|
|
|
|
|
|
2018-09-18 17:40:33 -04:00
|
|
|
Do take a look at the issue tracker.
|
2018-01-28 00:34:16 +03:00
|
|
|
|
|
|
|
|
If you don't know where to start, or have *any* questions or suggestions,
|
2018-10-04 21:43:58 +01:00
|
|
|
don't hesitate to chat at [Gitter]!
|
|
|
|
|
|
|
|
|
|
# Code generation
|
|
|
|
|
|
|
|
|
|
Some of the components of this repository are generated through automatic processes. These are outlined below:
|
|
|
|
|
|
|
|
|
|
- `gen-kinds`: The kinds of tokens are reused in several places, so a generator is used.
|
|
|
|
|
This process uses [tera] to generate, using data in [grammar.ron], the files:
|
|
|
|
|
- [ast/generated.rs][ast generated] in `ra_syntax` based on [ast/generated.tera.rs][ast source]
|
|
|
|
|
- [syntax_kinds/generated.rs][syntax_kinds generated] in `ra_syntax` based on [syntax_kinds/generated.tera.rs][syntax_kinds source]
|
|
|
|
|
|
|
|
|
|
[libsyntax parser]: https://github.com/rust-lang/rust/blob/6b99adeb11313197f409b4f7c4083c2ceca8a4fe/src/libsyntax/parse/parser.rs
|
|
|
|
|
[Kotlin parser]: https://github.com/JetBrains/kotlin/blob/4d951de616b20feca92f3e9cc9679b2de9e65195/compiler/frontend/src/org/jetbrains/kotlin/parsing/KotlinParsing.java
|
|
|
|
|
[Gitter]: https://gitter.im/libsyntax2/Lobby
|
|
|
|
|
[tera]: https://tera.netlify.com/
|
|
|
|
|
[grammar.ron]: ./crates/ra_syntax/src/grammar.ron
|
|
|
|
|
[ast generated]: ./crates/ra_syntax/src/ast/generated.rs
|
|
|
|
|
[ast source]: ./crates/ra_syntax/src/ast/generated.tera.rs
|
|
|
|
|
[syntax_kinds generated]: ./crates/ra_syntax/src/syntax_kinds/generated.rs
|
|
|
|
|
[syntax_kinds source]: ./crates/ra_syntax/src/syntax_kinds/generated.tera.rs
|
