Rust support for KDevelop
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Gospodinova, Emma
Rust was voted “most loved” language by developers for the second year in a row in the Stack Overflow developer survey. There have been projects made using Rust on everything from operating systems to game engines for Minecraft-like games. Despite this, IDE support is still very limited. As my Google Summer of Code project, I worked on a Rust plug-in for the KDevelop IDE which aimed to support most standard IDE features such as semantic highlighting, code completion, project management and debugging. I will go through the challenges of integrating language support in an existing IDE and talk about how adding semantic highlighting was one line of code and getting debugging to work took less than 10 minutes.
 Hi, everyone. I'm happy you're here to see the talk. So let's dive straight in. So a few words about me. So I am a third year undergraduate student at Imperial College London. I got into Rust. Well, I initially found out about Rust a couple of years ago, but I got more into it earlier this year, and I decided to do a GSOC project working on adding language support in K-develop for Rust. So yeah, so a bit about the project. So the main sort of part of the project is a library that I did, which essentially kind of takes information from the Rust compiler, from lip syntax, and then presents it to K-develop where I hooked up things, and yeah, basically, you'll see a bit later like the few demos from K-develop. So why not use the Rust language server? So the Rust language server is pretty cool. It essentially summarizes all the important information from the Rust compiler, and it presents it through the language server protocol. And this is great for editors like Visual Studio Code and Cade, for example, but specifically for K-develop, I found that it might not be the best approach because essentially K-develop expects a lot of internal structures to be built, and the K-develop core code, as not the language plugin, but the core of K-develop does a lot of things for you. So things like semantic highlighting, renaming declarations, finding usages, that kind of thing, like that's all done for you by K-develop as long as the language plugin builds these internal data structures. So what is ASD Redux? So it's a self-contained library. It's somewhat similar to Lib Clang, if you've seen that, or Cpython's ASD library. It's a bit lower level than RLS, so with RLS you would ask the language server something like, oh, tell me all the declarations for this particular symbol, or tell me all the usages for this particular symbol, and RLS would give all those to you. Here it's more like, oh, here's a bunch of symbols, you figure out what to do. It provides a view of the abstract syntax tree of the code, and it sort of, it exposes this as a C API, and it hides the details of working with lip syntax. So yeah, at the moment it's using lip syntax as a sort of platform to build on. In the future, I'm looking into getting more information from the Rust compiler and exposing that in a meaningful way as well. So how does this interact with K-develop? So K-develop essentially expects these internal data structures to be built. These are called the declaration use chain. Essentially what happens is, from K-develop I pass to ASD redux, the source code that it should parse and produce an ASD for, it does its thing, and then K-develop goes through the ASD and populates its internal data structures. So yeah, let's go on and see some of the things that you can do in K-develop. So like I said, essentially what happens is you go through the ASD, for each node you figure out if it's something like a function, a struct, an input, or anything else. You build the corresponding data structure in K-develop, and you're done. You get a lot of things for free at that point. So stuff like semantic highlighting. That's basically a single function call, and voila, K-develop figures out the rest for you. So let there be color. So yeah, renaming declarations or finding usages, whatever you want, same thing. Everything is basically done for you. So let's see if this will work. Yeah. So renaming a declaration, that's also, it sort of just works out of the box. With regards to building and debugging straight from the ID, again, K-develop has support for GDB and LLDB. So it was essentially a matter of getting those hooked up to work with Rust executables. And this as well works straight out of the box. You can run your code directly from K-develop. So same thing. You can add break points. You can see all of the variables, all their current values, step through the program, et cetera, et cetera, all the regular things you would want to do when debugging. So, yeah. Code completion. So code completion currently works for local declarations. I'm currently working on getting it set up for the Rust standard library. So this is proving to be a bit more interesting because a lot of, like, in the standard library, a lot of things are implemented with the help of macros. That expanding macros is an interesting process. So yeah. But I'm trying to work around that by sort of doing what a lot of other language plugins do, which is exposing, like, building essentially expanding the full source code of the standard library and then K-develop can just parse that directly. Or, yeah. And in the future, I'm looking to do the same thing for other libraries. So cargo has this great thing, which is it downloads the libraries, it checks them out from Git, and you can essentially find all the metadata, all the information you need to where those libraries are checked out and how you can, like, where you can find the source code, so you can go through that, parse that, and yeah, I'm looking to do that in the future. And similarly for project management, at the moment, you can create projects straight from K-develop. I'm looking in the future to expand the support for cargo integration. So the metadata that's provided by cargo for dependencies, for example, that can be parsed and the ID can then figure out how to do code completion and stuff like that for any libraries you're using. So yeah, I slightly rushed through this presentation because, yeah, I figured that I had a bit less time. But yeah, so for the future, like I mentioned, there's stuff like, there's a lot of stuff left to be done. Basically I've tried to make the library part of this project, which is AST Redux, a bit more agnostic, so it's not that tightly, it's not that sort of tightly integrated with K-develop. It can be used in other projects as well. So there's a lot of work that can be done there. So things like building straight, like essentially using the Rust compiler to build and extract any errors that are found in the code and expose those. There can be integration with RLS in the future. So yeah, stuff like that, there's a lot that can be done in this regard. So yeah, I'd like to say thank you to the organizers of this conference, Carol especially for inviting me to give a talk. And everyone in the Rust community that was so helpful throughout my GSOC project and was giving me lots of feedback and my mentors at KDE as well. So thank you, thanks to everyone, and thank you all for listening. So with that, I just want to say if you want to try out K-develop, come and see me at some point today and I can explain how you can do that, because at the moment it's based on the current master, so building everything from scratch might be a bit not straightforward. So yeah, come and see me at any point, I'm happy to help. So with that, are there any questions? Yeah. Can you find the source for the ASCVDX? Yeah, it's on GitHub. I can give you the link. Yeah? I want to say first off, this looks really nice. The demo was very cool. And I think it's a great idea. So I want to say first off, this looks really nice, the demo was very cool. And I was wondering about two questions. One is, since it's based on LibSyntax, and I know we've been making a few changes to LibSyntax in the last few months, have you been able to keep it up to date? Are you trying to keep it up to date? Like if I wanted to use it, besides having to build the master, would that be possible? Yeah, so at the moment, I am trying to keep it up to date. And the way I've set it up so that I can figure out when something breaks is I have a daily build on Travis set up. So if anything breaks overnight, like I get an email instantly. So I've been trying to keep up with those. There haven't been that many of those so far. So yeah. And the last question, are you doing things like name resolution yourself in order to link up the local variables? So that's one thing that I'm trying to decide on how to do exactly, because KDevelop does name resolution for you. But obviously, if I wanted to be sort of this agnostic library that can be used in other projects, then I would have to do name resolution within the Rust library. So at the moment, I'm using KDevelop's features to do name resolution, but I'm looking into moving that over into ASU Redux. Were there any like surprises or challenges that you had that came up when you were working on top of those syntax that you want to share? Oh, yeah. Yeah, lip syntax, I'm guessing because it was sort of built at a point where Rust didn't really have the error handling features it does today. So lip syntax panics on quite a few things like unexpected tokens. So for example, if there's a backslash somewhere, then it just panics. So stuff like that, I had to try to work around that. So I do, at the moment, I do the same thing as the Rust compiler, which is I spin it up in a new thread and wait to see what happens, basically. I think that I quite appreciated that KDevelop does a lot of these things for you. So I've worked with KDevelop in the past. So I sort of knew about this. And that's one of my main motivations of choosing to do it this way rather than using RLS because the way that KDevelop sort of handles these things behind the scenes, like if I had decided to do it with RLS, then if I decided to work with RLS, I would essentially have had to reimplement all of those things, which because KDevelop is kind of based on, like, it's kind of, it works with its own data structures. And at the same time, it's based on KATE. So things like the syntax highlighting is actually implemented in KATE. And KDevelop only says, okay, well, for these ranges, like, do this sort of coloring or whatever. And yeah, like, basically, if I decided to use RLS, all that code would become obsolete. So everything would have to be reimplemented on top of the language server protocol. So I think that would have been quite a bit more work. Yeah? You mentioned having some sort of mentorship. How did you get in touch with those mentors? So the Google Summer of Code program basically works like you submit a proposal and if there's interest from the organization to do that, to do that project, then they find mentors for you. So I was working with Kevin Funk who works on the C++ plugin in KDevelop. And yeah, like, he basically helped me a bit through, like, getting this, like, set up and that kind of thing. Yeah? What would you be hoping to achieve by integrating RLS in KDevelop? I guess stability because RLS is sort of actively developed by the Rust community. It has a lot of support from the core Rust developers as well. So essentially if anything changes at any point, I expect that that change would also be reflected in RLS. So what I'm trying to do with the library is sort of to expose it to expose the AST at the moment as through a C API, which is useful for something like KDevelop. But in the future, it might also be useful to get, like, further information like analysis from the compiler and that kind of thing exposed as well. So, like, with RLS, I think it would be, it would make it more stable basically. Like, I wouldn't have to keep track of all these changes. Yeah? Would it be completely impossible to be able to port your library to RLS and operate over the language service or the way it should be? I don't think it would be impossible. I think that would make the RLS a lot more useful for KDevelop, for example. So yeah, like, at the moment, RLS sort of implements the language server protocol, which doesn't really have any options for exposing the abstract syntax tree, for example. There are other similar protocols. I was pointed to one over the summer, but I don't have it off the top of my head, which language had that. But there was a sort of similar language server type software which exposed more information about the structure of the code to the ID. So if RLS had features like that, then it would be very useful for integrating with KDevelop, I think. One more question for me anyway. You mentioned that KDevelop does things like name resolution. It seems to me that there's likely to be rules and rust that KDevelop doesn't know about. And so would it be hard? Let's assume the RLS would be extended arbitrarily. Would it be hard to, if you did get, say, name resolution information from it, can you feed that also to KDevelop and say, okay, you don't have to resolve names? I can tell you the answer right now. Or does it not have that ability? I think it should be possible to do that. My guess is at the moment, yes, it's possible, but I'm not 100% sure on that. Yeah? You have any sense across IDEs and editors, different platforms, where the graphical debugging support is? Is there lots available or only a few different IDEs? Sorry, can you repeat? So outside of KDevelop, other IDEs, editors, do you know which ones have support for graph debugging from the editor versus not? I'm not sure. I imagine IntelliJ would have that. I haven't tried it recently, so I'm not sure. But yeah, like, I don't know. Sorry. I can answer that. IntelliJ, you cannot in IntelliJ itself, if you're using C-Lion, you can. And you can in VS Code via its LLDV integration, and you can with some work in Adam via its GDB or LLDV integration. So if you're someone who's not me, you could probably speak to them. Not to my knowledge, but with this, they stand in my knowledge. Okay. Thank you. Thank you. Thank you.
 Hi, everyone.  I'm happy you're here to see the talk.  So let's dive straight in.  So a few words about me.  So I am a third year undergraduate student at Imperial College London.  I got into Rust.  Well, I initially found out about Rust a couple of years ago, but I got more into it earlier  this year, and I decided to do a GSOC project working on adding language support in K-develop  for Rust.  So yeah, so a bit about the project.  So the main sort of part of the project is a library that I did, which essentially kind  of takes information from the Rust compiler, from lip syntax, and then presents it to K-develop  where I hooked up things, and yeah, basically, you'll see a bit later like the few demos  from K-develop.  So why not use the Rust language server?  So the Rust language server is pretty cool.  It essentially summarizes all the important information from the Rust compiler, and it  presents it through the language server protocol.  And this is great for editors like Visual Studio Code and Cade, for example, but specifically  for K-develop, I found that it might not be the best approach because essentially K-develop  expects a lot of internal structures to be built, and the K-develop core code, as not  the language plugin, but the core of K-develop does a lot of things for you.  So things like semantic highlighting, renaming declarations, finding usages, that kind of  thing, like that's all done for you by K-develop as long as the language plugin builds these  internal data structures.  So what is ASD Redux?  So it's a self-contained library.  It's somewhat similar to Lib Clang, if you've seen that, or Cpython's ASD library.  It's a bit lower level than RLS, so with RLS you would ask the language server something  like, oh, tell me all the declarations for this particular symbol, or tell me all the  usages for this particular symbol, and RLS would give all those to you.  Here it's more like, oh, here's a bunch of symbols, you figure out what to do.  It provides a view of the abstract syntax tree of the code, and it sort of, it exposes  this as a C API, and it hides the details of working with lip syntax.  So yeah, at the moment it's using lip syntax as a sort of platform to build on.  In the future, I'm looking into getting more information from the Rust compiler and exposing  that in a meaningful way as well.  So how does this interact with K-develop?  So K-develop essentially expects these internal data structures to be built.  These are called the declaration use chain.  Essentially what happens is, from K-develop I pass to ASD redux, the source code that  it should parse and produce an ASD for, it does its thing, and then K-develop goes through  the ASD and populates its internal data structures.  So yeah, let's go on and see some of the things that you can do in K-develop.  So like I said, essentially what happens is you go through the ASD, for each node you  figure out if it's something like a function, a struct, an input, or anything else.  You build the corresponding data structure in K-develop, and you're done.  You get a lot of things for free at that point.  So stuff like semantic highlighting.  That's basically a single function call, and voila, K-develop figures out the rest for  you.  So let there be color.  So yeah, renaming declarations or finding usages, whatever you want, same thing.  Everything is basically done for you.  So let's see if this will work.  Yeah.  So renaming a declaration, that's also, it sort of just works out of the box.  With regards to building and debugging straight from the ID, again, K-develop has support  for GDB and LLDB.  So it was essentially a matter of getting those hooked up to work with Rust executables.  And this as well works straight out of the box.  You can run your code directly from K-develop.  So same thing.  You can add break points.  You can see all of the variables, all their current values, step through the program,  et cetera, et cetera, all the regular things you would want to do when debugging.  So, yeah.  Code completion.  So code completion currently works for local declarations.  I'm currently working on getting it set up for the Rust standard library.  So this is proving to be a bit more interesting because a lot of, like, in the standard library,  a lot of things are implemented with the help of macros.  That expanding macros is an interesting process.  So yeah.  But I'm trying to work around that by sort of doing what a lot of other language plugins  do, which is exposing, like, building essentially expanding the full source code of the standard  library and then K-develop can just parse that directly.  Or, yeah.  And in the future, I'm looking to do the same thing for other libraries.  So cargo has this great thing, which is it downloads the libraries, it checks them out  from Git, and you can essentially find all the metadata, all the information you need  to where those libraries are checked out and how you can, like, where you can find the  source code, so you can go through that, parse that, and yeah, I'm looking to do that in  the future.  And similarly for project management, at the moment, you can create projects straight  from K-develop.  I'm looking in the future to expand the support for cargo integration.  So the metadata that's provided by cargo for dependencies, for example, that can be parsed  and the ID can then figure out how to do code completion and stuff like that for any libraries  you're using.  So yeah, I slightly rushed through this presentation because, yeah, I figured that I had a bit  less time.  But yeah, so for the future, like I mentioned, there's stuff like, there's a lot of stuff  left to be done.  Basically I've tried to make the library part of this project, which is AST Redux, a bit  more agnostic, so it's not that tightly, it's not that sort of tightly integrated with K-develop.  It can be used in other projects as well.  So there's a lot of work that can be done there.  So things like building straight, like essentially using the Rust compiler to build and extract  any errors that are found in the code and expose those.  There can be integration with RLS in the future.  So yeah, stuff like that, there's a lot that can be done in this regard.  So yeah, I'd like to say thank you to the organizers of this conference, Carol especially  for inviting me to give a talk.  And everyone in the Rust community that was so helpful throughout my GSOC project and  was giving me lots of feedback and my mentors at KDE as well.  So thank you, thanks to everyone, and thank you all for listening.  So with that, I just want to say if you want to try out K-develop, come and see me at some  point today and I can explain how you can do that, because at the moment it's based  on the current master, so building everything from scratch might be a bit not straightforward.  So yeah, come and see me at any point, I'm happy to help.  So with that, are there any questions?  Yeah.  Can you find the source for the ASCVDX?  Yeah, it's on GitHub.  I can give you the link.  Yeah?  I want to say first off, this looks really nice.  The demo was very cool.  And I think it's a great idea.  So I want to say first off, this looks really nice, the demo was very cool.  And I was wondering about two questions.  One is, since it's based on LibSyntax, and I know we've been making a few changes to  LibSyntax in the last few months, have you been able to keep it up to date?  Are you trying to keep it up to date?  Like if I wanted to use it, besides having to build the master, would that be possible?  Yeah, so at the moment, I am trying to keep it up to date.  And the way I've set it up so that I can figure out when something breaks is I have a daily  build on Travis set up.  So if anything breaks overnight, like I get an email instantly.  So I've been trying to keep up with those.  There haven't been that many of those so far.  So yeah.  And the last question, are you doing things like name resolution yourself in order to  link up the local variables?  So that's one thing that I'm trying to decide on how to do exactly, because KDevelop does  name resolution for you.  But obviously, if I wanted to be sort of this agnostic library that can be used in other  projects, then I would have to do name resolution within the Rust library.  So at the moment, I'm using KDevelop's features to do name resolution, but I'm looking into  moving that over into ASU Redux.  Were there any like surprises or challenges that you had that came up when you were working  on top of those syntax that you want to share?  Oh, yeah.  Yeah, lip syntax, I'm guessing because it was sort of built at a point where Rust didn't  really have the error handling features it does today.  So lip syntax panics on quite a few things like unexpected tokens.  So for example, if there's a backslash somewhere, then it just panics.  So stuff like that, I had to try to work around that.  So I do, at the moment, I do the same thing as the Rust compiler, which is I spin it up  in a new thread and wait to see what happens, basically.  I think that I quite appreciated that KDevelop does a lot of these things for you.  So I've worked with KDevelop in the past.  So I sort of knew about this.  And that's one of my main motivations of choosing to do it this way rather than using RLS because  the way that KDevelop sort of handles these things behind the scenes, like if I had decided  to do it with RLS, then if I decided to work with RLS, I would essentially have had to  reimplement all of those things, which because KDevelop is kind of based on, like, it's kind  of, it works with its own data structures.  And at the same time, it's based on KATE.  So things like the syntax highlighting is actually implemented in KATE.  And KDevelop only says, okay, well, for these ranges, like, do this sort of coloring or  whatever.  And yeah, like, basically, if I decided to use RLS, all that code would become obsolete.  So everything would have to be reimplemented on top of the language server protocol.  So I think that would have been quite a bit more work.  Yeah?  You mentioned having some sort of mentorship.  How did you get in touch with those mentors?  So the Google Summer of Code program basically works like you submit a proposal and if there's  interest from the organization to do that, to do that project, then they find mentors  for you.  So I was working with Kevin Funk who works on the C++ plugin in KDevelop.  And yeah, like, he basically helped me a bit through, like, getting this, like, set up  and that kind of thing.  Yeah?  What would you be hoping to achieve by integrating RLS in KDevelop?  I guess stability because RLS is sort of actively developed by the Rust community.  It has a lot of support from the core Rust developers as well.  So essentially if anything changes at any point, I expect that that change would also  be reflected in RLS.  So what I'm trying to do with the library is sort of to expose it to expose the AST  at the moment as through a C API, which is useful for something like KDevelop.  But in the future, it might also be useful to get, like, further information like analysis  from the compiler and that kind of thing exposed as well.  So, like, with RLS, I think it would be, it would make it more stable basically.  Like, I wouldn't have to keep track of all these changes.  Yeah?  Would it be completely impossible to be able to port your library to RLS and operate over  the language service or the way it should be?  I don't think it would be impossible.  I think that would make the RLS a lot more useful for KDevelop, for example.  So yeah, like, at the moment, RLS sort of implements the language server protocol, which  doesn't really have any options for exposing the abstract syntax tree, for example.  There are other similar protocols.  I was pointed to one over the summer, but I don't have it off the top of my head, which  language had that.  But there was a sort of similar language server type software which exposed more information  about the structure of the code to the ID.  So if RLS had features like that, then it would be very useful for integrating with  KDevelop, I think.  One more question for me anyway.  You mentioned that KDevelop does things like name resolution.  It seems to me that there's likely to be rules and rust that KDevelop doesn't know about.  And so would it be hard?  Let's assume the RLS would be extended arbitrarily.  Would it be hard to, if you did get, say, name resolution information from it, can you  feed that also to KDevelop and say, okay, you don't have to resolve names?  I can tell you the answer right now.  Or does it not have that ability?  I think it should be possible to do that.  My guess is at the moment, yes, it's possible, but I'm not 100% sure on that.  Yeah?  You have any sense across IDEs and editors, different platforms, where the graphical debugging  support is?  Is there lots available or only a few different IDEs?  Sorry, can you repeat?  So outside of KDevelop, other IDEs, editors, do you know which ones have support for graph  debugging from the editor versus not?  I'm not sure.  I imagine IntelliJ would have that.  I haven't tried it recently, so I'm not sure.  But yeah, like, I don't know.  Sorry.  I can answer that.  IntelliJ, you cannot in IntelliJ itself, if you're using C-Lion, you can.  And you can in VS Code via its LLDV integration, and you can with some work in Adam via its  GDB or LLDV integration.  So if you're someone who's not me, you could probably speak to them.  Not to my knowledge, but with this, they stand in my knowledge.  Okay.  Thank you.  Thank you.  Thank you.
Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_0_59.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_60_1259.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_1260_1367.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_1368_1487.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_1488_1643.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_1644_7703.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_7704_8807.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_8808_8939.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_8940_14459.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_14460_15035.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_15036_15143.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_15144_15239.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_15240_16427.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_16428_16595.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_16596_17171.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_17172_17507.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_17508_17663.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_17664_17735.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_17736_17915.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_17916_18587.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_18588_22571.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_22572_26651.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_26652_32063.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_32064_34367.png Rust_support_for_KDevelop___Emma_Gospodinova_2_cOkRXhveY_34368_34411.png