I've contributed to KDevelop in the past, on the Python plugin, and so far working on the Rust plugin, my impressions from back then were pretty much spot-on. KDevelop has one of the most well thought-out codebases I've seen. Specifically, KDevPlatform abstracts over different programming languages incredibly well and makes writing a new language plugin a very pleasant experience.The Declaration-Use ChainThe Declaration-Use Chain stands at the core of this. It's a simple enough concept: there are things in the language which are declared somewhere and used in other places. Declarations are a generalization of programming language constructs: structs, struct fields, functions, methods, locals, etc. Declarations can open contexts and any declarations in a child context are valid in that context only. For example, functions open a new context for declarations inside the function body. Uses are, well, what you'd expect: instances where these language constructs are used.
Obviously, there's some details I skipped here, but the beauty in all of this is that KDevelop can figure out a lot of things for you if it simply has access to this information.The Rust CompilerThe Rust compiler is also really well designed in that it allows accessing the internals such as the syntax parsing library. It's not necessarily the nicest thing, as the internals are intentionally marked unstable, but given that a lot of other tools for working with Rust source code like RLS also depend on compiler-internal libraries, I think this is an acceptable compromise.
These will likely stabilise over time, especially given the amount of effort being put into the save-analysis API. Speaking of which, one thing missing that would be very useful is to be able to get the full span of declarations that have an internal context (e.g. the span that covers the body of a function).
My main effort on the Rust side is trying to expose a C API to the compiler structures that is more independent from the compiler internals themselves. Think libclang. I think something like this would make adding support in other IDEs easier. I'm currently looking into hooking into the various stages of the compiler in order to get both the pre- and post-expansion AST, as well as type information inferred by the compiler (though I'll likely try to implement this myself first for the learning experience :)).Building the DU Chain for Rust codeAnd now the fun part: how these fit together. Here is a before and after:
Much better. Going forwardThere are things still missing here; as you may have noticed, uses are not highlighted. I have to admit, I fell about a week and a half behind schedule due to a university group project which was more time consuming than I initially expected as well as my attempt to think through how to best expose certain things as a C API from Rust before writing a significant amount of code. Thankfully, I accounted for some delays like this in my original timeline, so this should be recoverable from.
Right now, I'm aiming to finish adding the missing elements of the DU Chain by the end of this week and then I'll start looking into code completion.
Or: Tying loose ends where some are slightly too short yet. When you favour offline documentation (not only due to nice integration with IDEs like KDevelop), develop code using KDE Frameworks or other Qt-based libraries, you know all the KF5 libraries have seen many people taking care for API documentation in the code over all … Continue reading Adding API dox QCH files generation to KDE Frameworks builds
After my post last week that I would be implementing the Rust plugin the classic way (that is, manually parsing, deriving type information, figuring out completions, refactorings, etc.), I received quite a few replies about the language server protocol and RLS specifically. I'd like to address RLS in more detail, since some of the replies were rather strongly-worded and sounded a bit patronizing.The Good: in defense of language serversGiven that I will be criticising the language server protocol for the remainder of this post, I want to note that I'm not against the concept. I quite like it, actually. Language servers work great with lightweight editors: implement the protocol once and the editor becomes reasonably powerful for any language which has a corresponding language server. Visual Studio Code is a great example of an editor that benefits from language servers, which I guess is quite obvious given that the language server protocol was practically designed for VSCode. Still, others like Atom, Sublime, Vim and Emacs would also greatly benefit from the language server protocol. (Now, whether I would personally use it in Vim is a whole different story.)
From what I've seen in the language server protocol docs, that's pretty much what they're pushing the protocol for, at least for the time being. I think the language server protocol needs a lot more additions in order for it to be useful for IDEs. Which brings me to my point.The BadIDEs are not just editorsThe thing is, IDEs have to support many things besides just the language itself; debugging and project management come to mind, but for those, the IDE doesn't necessarily need to know much about the language. For other things, such as static analysis, type hierarchy, dependencies, etc., the IDE needs to understand the language. And yes, you could argue that these functions can be implemented by the language servers, but the thing is, they're not just unavailable at the moment for some language servers, the protocol itself does not specify how they should be implemented.LSP is incompleteThe protocol currently only specifies very basic functionality: autocompletions, quick fixes, semantic highlighting, finding uses, formatting and that just about covers it. This is nothing compared to things a good IDE can do. Specifically when it comes to code generation, I think that's where IDEs truly shine, but at the moment LSP does not specify how to do general code generation.LSP is inextensibleSure, individual language servers can extend the language server protocol with additional methods, such as rustDocument/diagnosticsBegin and rustDocument/diagnosticsEnd, but considering the point of the language server protocol is to reduce the amount of work necessary for tool developers, there is little incentive to keep track of every language server's extensions.And The UglyMaking an IDE jump over its own data structures is just plain uglyMost large IDEs are built using a plugin-based architecture, in order to support many languages, and the core usually has some abstract language structures. Declarations and uses; the different kinds of language objects like functions, locals, classes, structures, etc. And just based on those, the IDE can implement a whole lot of functionality like go-to-declaration, rename, semantic highlighting, etc. All the language plugin needs to do is to populate these structures.
The problem with language servers is that they take all of that information away from the IDE. So in the end, it doesn't matter that you don't need to do parse and understand the language since the language server can do it for you, because you end up having to reinvent the wheel anyway by having to reimplement the core functionality to depend on the language server, rather than language support plugins.How it can be improvedJust bashing on the protocol is not particularly useful for anyone, so I want to suggest a way many of these problems can be avoided: provide code structure information. Instead of trying to rip away the main component of an IDE from it, allow the IDE to work with the language server. There's no point in the IDE asking the language server what to highlight when the cursor is on a variable if the language server just tells the IDE where the declaration and where all the uses of that variable is in that document.
There's no need to remove any existing functionality either and the language server already computes all this information anyway! If it's exposed to the client, the client can decide if it wants/needs to use it or not.And yet ignoring all of that, RLS is lacking in functionalityI decided to spend 72 hours last week implementing (a significant part of) the language server protocol in KDevelop in order to prove a point: RLS still doesn't even support many of the features that the language server protocol permits.
Completion support for locals works and not much else.
No completions for functions of something. (The ones shown are keyword completions from Kate.)
No completions could be triggered here. RLS returns an empty list.
No contextual completions: we are in a match block for foo, which is an Option type, which is an enum. It is reasonable to expect that we can autocomplete the enum values.
And this is just code completion. RLS returns empty lists for the documentSymbol and documentHighlight methods, hence why only the syntax highlighting from Kate is available. I haven't tried references, but since RLS computes that identically to documentHighlight, I expect it won't work either. The hover method doesn't work either. Even if the reason for those not working is that I missed setting up something (it happened initially with code completions requiring racer which needed an environment variable to be set), having the user set up all of this manually is not at all user-friendly.
Go-to-definition works. I haven't tried the formatting stuff, but that calls rustfmt, which the IDE can do by itself.
No other methods are supported by RLS at the time of writing. So things like searching for a struct or function in the project, getting information about a function signature, quick fixes, refactorings, etc. are not available.
My project proposal was to create a plugin providing good support for Rust in KDevelop. I intend to deliver on that project, but I do not think at its current state RLS provides good support. That may change in the future and I've shown a proof of concept that KDevelop can interact with a language server. Right now, I think I can do better.
Also, Rust's type system is inspired by the Hindley-Milner type inference algorithm. :D No way am I missing the opportunity to implement type inference. After all, Google Summer of Code is an opportunity for me to learn more about things I find interesting.
On my last blog post I discussed about how some assumptions such as the platform developed on can affect our development. We need to minimize it by empowering the developers with good tools so that they can develop properly. To that end, I introduced runtimes in our IDE to abstract platforms (much like on Gnome’s […]
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 introMy 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...RustRust 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...KDevelopKDevelop 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 codeArguably 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...
KDevelop, your cross-platform IDE, since version 5.1 has initial OpenCL language support. If you are into OpenCL and interested, we need your help for some improvement to that: What is the mimetype name to use for OpenCL C files? Due to KDevelop needs some weeks ago a mimetype for OpenCL has already been added to … Continue reading Give us a proper mimetype name for OpenCL C files!
Let's start with some luridness:
Now from the beginning: I got to know quite a few people in the past decade (phew, I'm such a dinosaur!) who use Kate as their editor of choice to hack on C++ code, on a daily basis. While I totally agree Kate is an
just a short heads-up that KDevelop is seeking for a new maintainer for the Ruby language support. Miquel Sabaté did an amazing job maintaining the plugin in the recent years, but would like to step down as maintainer because he's lacking time to continue looking after it.
You might have noticed there's KDevelop for Windows out now...
Which is already great in itself! But now it's also possible to install it via the super popular Windows package manager for Windows, Chocolatey.
Here's all you need (in case you already have Chocolatey installed on your system):
Almost two years after the release of KDevelop 4.7, we are happy to announce the immediate availability of KDevelop 5.0!
While the release announcement on kdevelop.org is kept short intentionally, this blog post is going more into depth, showing what's new in KDevelop 5.0.
On Sunday, this year’s KDE sprint in Randa, Switzerland came to an end and I am now back home. It was a productive and fun week, as always when meeting the other KDE folks. I spent a lot of time on polishing things and fixing small issues mostly in KDevelop, such as: reduce flickering of the completion widget in kdevelop fix various cases where KDevelop’s navigation widget (see above) would […]
I am currently at the KDE sprint in Randa, Switzerland. There are about 40 nice people here, working on making KDE software awesome. This year’s focus is on deploying our software more nicely — on Windows and OS X, but on Linux as well. Especially for user-faced applications like KDevelop, it really makes a big difference whether you use today’s version, or the one from two years ago. Many people […]
Right now, around 40 developers are working together on bringing KDE to other platforms in Randa (Switzerland) for an entire week.
I just arrived Sunday evening, and we immediately started with discussions around KDE on different platforms. Not much coding has happened yesterday evening yet, but I at least managed
Note: These instructions apply for Ubuntu 16.04, too
Recently, I've got several mails from people desperately trying to compile KDevelop on Ubuntu-based distros. Let's give them a hand by providing them a quick start guide!
This is a brief version of what's in https://community.kde.org/Frameworks/Building
I spent the last two or three days playing around with KDE on Windows, with the aim of getting my Python language plugin for KDevelop to run there. In the end, it wasn’t that hard to get this to work — not as hard as I would have expected it to be, anyways. Several things needed to be fixed in kdev-python, the build system required a bit of tickling, but […]
I have the pleasure to announce the releases of two new KDevelop versions:
On one hand, there is the new and shiny KDevelop 5.0 Beta 2 release, which brings us much closer to a final release. Tons of issues have been resolved, many features got polished, and even our UI cleaned up a bit here and there. And did I mention impoved OS X and Windows support? See here for more:
Besides this new beta release, which is where most of our effort went into, I am also happy to announce KDevelop 4.7.3, a new bugfix release of our latest stable KDE 4 based KDevelop. Several annoying problems are resolved now, see the announcement for more information:
Many thanks to everyone involved!
displaying size meta data of classes and members in KDevelop thanks to Clang
I’m very glad to finally announce the first beta of KDevelop 5.0.0, based on Qt 5, KF 5 and Clang: https://www.kdevelop.org/news/first-beta-release-kdevelop-500-available
Like I’ve said previously, I’m very thankful of the tons of contributors that made this step possible. From the early testers, over the many new KDevelop contributors who helped a lot in porting our code base to Qt 5 and KF5, to the people that worked on improving kdev-clang and all the other areas. It’s a great feeling to finally release this beast. A year ago, just after we started in this process, I still wasn’t too sure we can pull it all off. Now, look where we are :) “Just” a few more weeks of polishing and I’m positively sure KDevelop 5.0.0 will be a really good milestone.
That said, I also want to express my thanks towards the KDE e.V. which graciously sponsored our recent KDevelop/Kate sprint in Berlin. We rented a flat for the 8 hackers that visited Berlin and had a productive five days directly after the Qt World Summit. Personally, I worked on kdev-clang and polished it a bit more in the preparation of the first beta release. One handy feature I added is the display of size information about classes and member variables, displayed in the image to the right.
If you want to give back to the KDevelop community, please consider a donation to the KDE e.v., which is used for our yearly developer sprints and the Akademy conference.
Copyright 2016· All rights reserved