Main navigation

KDevelop 5.1.0 released

Submitted by kfunk
on Tue, 2017/03/21 - 11:00

We are happy to announce the release of KDevelop 5.1! Tons of new stuff entered KDevelop 5.1. Here's a summary of what's new in this version:

LLDB support

We had a great student for GSoC 2016 implementing LLDB support in KDevelop. The end result is that we now have a debugger framework which can be used both for the GDB & LLDB MI communcation. The LLDB plugin teaches KDevelop to talk to the standalone LLDB MI Driver (lldb-mi); so now it's possible to use LLDB as an alternative debugger backend for KDevelop. One interesting thing with LLDB that it's also potentially useful on OS X & Windows for us, especially when the Windows port of LLDB is getting more and more stable.

Analyzer run mode

With 5.1, KDevelop got a new menu entry Analyzer which features a set of actions to work with analyzer-like plugins. During the last months, we merged analyzer plugins into kdevelop.git which are now shipped to you out of the box:

Cppcheck

Cppcheck is a well-known static analysis tool for C/C++ code. Cppcheck is useful for taking a closer look at your source code checking for common programming faults such as out of bounds accesses, memory leaks, null pointer dereferences, uninitialized variables, etc. pp. With the Cppcheck integration in KDevelop running the cppcheck executable is just one click away. KDevelop will pass the correct parameters to cppcheck including potential include paths and other options.

KDevelop with Cppcheck integration

Other analyzers in the pipeline: Valgrind, clang-tidy, krazy2

While the Cppcheck plugin is shipped out of the box, other analyzers are not considered 100% stable yet and still reside in their own repositories. The clang-tidy plugin looks super promising (another static analysis & refactoring tool for C/C++) as it really easy to use from the command-line and thus easy to integrate into our IDE. We plan to import more of those analyzers into kdevelop.git so they'll be part of the kdevelop tarball and are thus available to you without having to install yet another package.

Initial OpenCL language support, CUDA support upcoming

Since 5.1 KDevelop is able to parse code written in the Open Computing Language (OpenCL). The OpenCL language support inside KDevelop is backed by our Clang-based language support backend and thus just required minimal changes in KDevelop to start supporting it. Support for handling NVidia's CUDA files will be part of 5.2 instead. Stay tuned.

Properly highlighted OpenCL file in KDevelop

Note that for KDevelop to detect .cl files as OpenCL files, an up-to-date shared-mime-info package which contains this patch is required. Alternatively, you can add the mime type yourself by creating the file /usr/share/mime/text/x-opencl-src.xml with appropriate contents and re-running update-mime-database yourself.

Improved Python language support

Python language support now supports Python 3.6 syntax and semantics. In addition, thanks to the work of Francis Herne, various long-standing issues in the semantic analysis engine have been fixed:

Loops and comprehensions infer types correctly in many more cases, including on user-defined types with __iter__ and __next__ methods.

Type guessing works for arguments named by keywords (not only **kwargs), and works better for class/staticmethods.

Property accesses get the return type of the decorated method.

Types are inferred correctly from PEP-448 syntax in container literals.

Unsure types are handled in subscripts and tuple unpacking.

Uses are found for __call__() and __get/setitem__().

These improvements were accompanied by cleaning up dusty code, making future changes simpler as well.Furthermore, our style checker integration has been rewritten, making it much faster and easier to configure.

Some of the newly-handled Python language features.

Perforce integration

Thanks to Morten Danielsen Volden we now have Perforce integration in kdevplatform.git, which can be used freely starting with KDevelop 5.1. Perforce is a commercial, proprietary revision control system. The Perforce integration in KDevelop simply works by running a local version of the p4 executable (needs to be installed independently of KDevelop) with appropriate parameters. This is similar to how KDevelop integrates with other VCS, such as Git & Bazaar.

Color scheme selection inside KDevelop

It is now possible to select the current color scheme from within KDevelop, a feature which has been requested several times in the past. This is especially useful for when KDevelop is run under a different desktop environment than KDE Plasma, where the color scheme settings may not be easily accessible.

Selecting the current color scheme inside KDevelop

Ongoing support for other platforms

We're continuously improving the Windows version of KDevelop and we're planning to release a first KDevelop version for OS X soon (yep, we're repeating us here, please stay tuned!). For the Windows version, we upgraded the KF5 version to 5.32 and the LLVM/Clang version to 3.9.1.

Get it

Together with the source code, we again provide a prebuilt one-file-executable for 64-bit Linux, as well as binary installers for 32- and 64-bit Microsoft Windows. You can find them on our download page.

KDevelop 4 did not have Perl support, and what KDevelop 3 (over 10 years ago) had in terms of language support was much more simplistic than what we consider a supported language nowadays. In this sense I wouldn't say KDevelop ever supported perl.
It's a lot of work to get a language supported, and we don't have the resources to add support for Perl at the moment. If you are interested in working on that, you are very welcome of course!

(1): Not really, at this point
(2): Yes, it's theoretically possible to integrate clazy so the internal parser of KDevelop actually reports clazy issues, but there are some difficulties to do this with a distro-packaged libclang. So, plans, yes, but they haven't materialized yet.

Although KDevelop is steadily maturing, there are some minor issues. I want to have 2 toolviews at each side and in the center the code. But when I restart KDevelop, these toolviews are either closed or another is open in their respective position. But not just after a restart, but even after a commit or returning from Debug mode to Code.

The same applies for some config options. Let's say I want to enable "Look ahead in code" or apply a certain formating style with astyle. Each time I restart it, I have to enable those again.

Stonking release, except for one crippling (for me) bug: Using mint cinnamon, editor window does not regain focus in various situations including switching from source to header file with keyboard shortcut.