Stream: t-compiler/wg-rls-2.0

Topic: non-generic rowan


matklad (Apr 05 2019 at 09:18, on Zulip):

Would love to get some feedback on https://github.com/rust-analyzer/rowan/pull/13

This PR makes the sytnax tree library we use non-generic, which might be a good trade off considering that the tree itself never uses generic parameters itself.

Gary Tierney (Apr 28 2019 at 12:33, on Zulip):

I've been using rowan as the underlying framework for my parser and I'm a big fan of this. Is there any appetite in pulling out rust-analyzer/ra_parsers event-driven parsing framework to rowan (or a separate crate)? I think it has a lot of potential for generic IDE tooling, e.g., could be used to build a Rust solution to IntelliJ's GrammarKit.

matklad (Apr 28 2019 at 12:37, on Zulip):

@Gary Tierney I've actually experimented with rust Grammar Kit thing before rowan: https://github.com/matklad/fall

matklad (Apr 28 2019 at 12:37, on Zulip):

was able to parse full rust with ti: https://github.com/matklad/fall/blob/master/lang/rust/syntax/src/rust.fall

matklad (Apr 28 2019 at 12:38, on Zulip):

As for pulling away the parsing framework, that's a good question!

matklad (Apr 28 2019 at 12:38, on Zulip):

I am increasingly becoming convinced that parser and syntax tree should be completely orthogonal

matklad (Apr 28 2019 at 12:39, on Zulip):

So, there probably shouldn't be "rowan-specific" parser framework

matklad (Apr 28 2019 at 12:40, on Zulip):

I am however not sure how exactly the API between the parser and the tree builder should look like

matklad (Apr 28 2019 at 12:40, on Zulip):

the main question here is "to type or not to type" :-)

matklad (Apr 28 2019 at 12:41, on Zulip):

If we go with untyped version, that something like IntelliJ's marks (don't remmeber how they are called) should work

matklad (Apr 28 2019 at 12:42, on Zulip):

However, the API should allow to construct a typed tree as well, and I don't know how to do that nicely

matklad (Apr 28 2019 at 12:42, on Zulip):

that actually is an extremely interesting question! One thing we'd want to do in the future is to share the parser between rust-analyzer and rustc, and this setup will require us to have this kind of abstract parser

Gary Tierney (Apr 28 2019 at 12:44, on Zulip):

e.g., a tree of some syntax tree type T, as opposed to a tree of rowan::SyntaxKind?

matklad (Apr 28 2019 at 12:47, on Zulip):

Not just a single type T, but like a tree of StructDef which has FieldDefs inside

matklad (Apr 28 2019 at 12:47, on Zulip):

Like, when you write traditional parser, the types in AST guide you

Gary Tierney (Apr 28 2019 at 12:52, on Zulip):

hmm, I will think about that a bit and how it might fit into the existing TreeSink work. I can appreciate the independence of syntax tree and parser. I think that's what enables making rapid changes to this sort of stuff.

Last update: Nov 19 2019 at 19:00UTC