Summer of Coding!

After a month of dread and panicking about the fact that Google Summer of Code results are announced in the middle of exam season... I'm happy to say I'll be doing the Rust plugin for KDevelop!

Quick intro

My name is Emma. Just turned 21. I'm a second-year undergrad at Imperial College London. Been programming since I was 10. I've worked on a bunch of different projects over the years. Many of them are open source. I've contributed to the KDevelop Python plugin previously. I worked at Microsoft Research in summer 2016 on the AssessMS project. I'm interested in a couple of different areas of computer science: artificial intelligence, computer vision, and lately compilers, type systems and operating systems. Favourite languages: Haskell, C++ and as of recently...

Rust

Rust is a rather new programming language, but it's already gained a lot of traction. It was voted “most loved” language by developers for the second year in a row in the StackOverflow 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 lacking. This has to change...

KDevelop

KDevelop is a really great IDE, but it currently does not support Rust at all. However, it does have an easily extensible plugin architecture, so the logical conclusion is to write a Rust plugin! 

And there you have it. That was basically my reasoning when applying to KDE to do this project.

What now?

I had a bit of a snag with timing: my university exams were basically back to back for the past three weeks, and May is supposed to be used for community bonding, so I'm a bit behind on that. However, I have been playing around with Rust quite a bit (I started writing a small OS kernel because why not). Rust does interface quite nicely with C (aside from half of the code being littered with 'unsafe's). Still, this means my initial idea should work quite nicely. The plan is to get all necessary packages and a skeleton project set up by May 30 when coding begins.

The plan for the next month: parsing Rust code

Arguably the most difficult part of this whole project. Rust is, in my opinion, very similar to C++ when it comes to parsing (that is, a nightmare). So the plan is basically not to do any parsing at all. Bear with me for a moment.

The Rust compiler is nicely split up into different modules. One of those is the syntax parsing library, appropriately named libsyntax. Normally, it's private, except in the Rust nightly compiler (mainly for debugging purposes I suppose). However, a fork of it is available for the stable branch, named the syntex_syntax package. Several other Rust tools including rustfmt, Rust Racer and Rust Language Server use this package, so I'll assume it's stable.

It does the parsing and provides a nice visitor-pattern approach to traversing the AST. Hook this up to C++ with some foreign function calls and that's about it for parsing.

Semantic highlighting at this point becomes a matter of traversing the AST produced by the syntax parsing library (which includes the ranges of all elements), and constructing the appropriate structures on KDevelop's side.

And afterwards...

The final goal is to have full language support, which includes semantic highlighting, navigation, code completion, as many possible code refactoring/generation options as possible, and debugging. Some of these partially overlap: highlighting, navigation and completions all depend on building a knowledge base of the code. Debugging, should be a matter of hooking up GDB/LLDB, which KDevelop already supports, for Rust-compiled objects. Finally, refactoring and code generation should be quite fun to do, and I think that would make KDevelop the Rust IDE.

Stay tuned for updates...

Comments

  1. This comment has been removed by the author.

    ReplyDelete
  2. Do you thought of using the language server protocol? And there is the official rust language server. I think that would be better than implementing your own parser etc.

    ReplyDelete
    Replies
    1. Yes I considered it and decided against it. The Rust Language Server is great, but in the end it uses the same parsing method I've proposed, and working with the language server protocol basically means putting responsibility of knowing about the language into the hands of the language server, which means that the IDE will be limited to what the language server protocol permits, which at the moment is not an awful lot.

      Delete
    2. I strongly believe in language server protocol. I know it doesn't perform that good, but it's the official tool for IDE supporting. So it is going to be much better. Also there is a lot more than just syntax highlighting for the IDEs, like showing lints, refactorings, etc. And language server protocol covers almost all the requirements, but not all of them implemented for rust implementation (yet!). Please, begging you to use RLS. So many language support in ides doesn't see that much attention after the initial release. But if you use RLS it will be allways up to date with the latest rust features. And thank you for integrating rust into kdevelop!

      Delete
  3. IIRC, syntex is no longer actively maintained, unless that's changed since the thread on the users board looking for a new maintainer. for it. `syn` is the new crate that serde and other projects have moved to, and it's quite good.

    ReplyDelete
  4. Fair enough. Thanks for letting me know, I'll have a look.

    ReplyDelete
  5. Hi Emma,

    I really looking forward for Rust support in KDevelop. Both are my favourite instruments.

    However, I strongly advise you to have a closer look at the RLS project (https://github.com/rust-lang-nursery/rls). It's an implementation of Language Server Protocol for the Rust ecosystem.

    Currently RLS provides experimental yet solid environment for any IDE that want's Rust support. It solves many issues related to source code and project management including Cargo support, code navigation, tight compiler integration and various refactorings.

    Moreover it has reference client implementation for Visual Studio Code.

    I think, it would not be wise to throw all 2 years of work away and start from scratch.

    ReplyDelete
  6. I agree with Roman. Use of RLS is absolutely neccessary.

    You see, language support is not about syntax, it's all about types. Descent language support plugin must provide code completion feature. And to be able to complete the Rust expression is impossible without complex reasoning, type inference and all that stuff that compilers do.

    Even RLS nowadays is stuggling to complete expressions after dot, like: 'something.|' where pipe symbol represents the cursor position. If 'something' is a structure and it's definition is in scope, then you may probably provide a hint on it's fields.

    But all gets very compicated when we start thinking about traits, type bounds, specialization and polymorphism. Roughly half of the compiler's logic is needed to "simply" aswer the question "what methods are accessible from this point for this type".

    And now the good thing: you do not need to do all that stuff yourself!

    Just use the RLS and all will be fine. RLS is written and maintained by people that are active members of the Rust community so simply let them do their job.

    I really looking forward to descent Rust support in KDevelop and believe that it's simply impossible without RLS.

    ReplyDelete
    Replies
    1. I have to second that. The C/C++ plugin was just recently switched from self made heuristics to using libclang and it is much much better now.
      RLS is the way to do it. I like neither Microsoft nor json but it's, what the rust team has chosen so it will always have the best language support.
      Any missing features will have to be added there.

      Delete

Post a Comment

Popular Posts