CLion 2018.2 released: clangd, Gradle and compilation database projects, Google Sanitizers, and database support
Since CLion 1.0 first came out in April 2015, it has been growing steadily. Still, there are many areas for improvement, and we feel a responsibility – both to our current customers and those still waiting for some critical functionality to be added before they adopt CLion – to make progress in these areas. Hopefully, this release moves us one step closer to making good on that promise.
In this release, we’ve done our best to deliver some very important new capabilities for both groups. On the one hand, CLion comes with an experimental complementary clangd-base language engine and a set of important performance improvements. On the other, it introduces support for several new project models, which may open the door to a public project model API in the future.
Read on for more details (or don’t), but make sure to grab your free 30-day trial to evaluate all the new features and enhancements:
- C++ language support:
- IDE performance improvements
- Project models:
- New tools:
- Debugger fixes for GDB and LLDB.
- Ability to recompile a single file to speed up the development cycles.
- The latest goodies from IntelliJ Platform, plus other improvements.
For a quick overview of the new features and enhancements, watch this video from Phil Nash:
C++ language support
Clangd as an experimental complementary C++ language engine
CLion now uses a clangd-based language engine in addition to its own language engine. This new experimental engine is turned on by default on Linux and macOS platforms in v2018.2, on Windows in v2018.2.1. Note it’s used only to show errors and warnings in the editor, while the rest of code insight features (i.e. quick-fixes, refactorings, completion, navigation, etc.) are not affected. Read our recent blog post for more details.
If you want to turn this engine off or customize which warnings and errors it detects, go to Settings/Preferences | Languages & Frameworks | C/C++ | Clangd:
What’s next? Good question! We’ll proceed with this complementary language engine to see if the combination works to ensure more accurate and quick code insight in CLion. We’ll also consider moving other code insight features to the clangd-based engine where possible, but can’t promise anything for sure at this stage. That’s why it’s called experimental for now. We’ll keep working on our own language engine too in the meantime. Stay tuned!
C++ support fixes and new inspection
A new inspection is now available to detect situations when the arguments of the same type are passed in the wrong order. This requires the parameter names to be meaningful, and the algorithm relies on several heuristics. Isn’t it great to catch this annoying error even before compiling your code?
Note, the inspection requires the clangd-based experimental language engine to be enabled.
We’ve kept advancing CLion’s own language engine, which is the basis for all smart IDE actions like code navigation, refactorings, code generation, and more. A set of enhancements for various cases have been implemented.
IDE performance improvements
We keep reworking critical components step by step to boost the IDE’s performance. And our focus is now on eliminating UI freezes. Version 2018.2 addresses a range of issues in this area. The most noticeable ones are related to the UI freezing after a VCS update, navigating to the related symbol (and thus switching between .h and .cpp files), UE4 projects freezing, and others.
The biggest improvement is probably our lexer-only indentation processor. Running the formatter on a lexer is obviously faster than doing a full parse and resolve of C++ code. We believe this change will improve the editor performance for many of our users. However, inaccuracies are possible in some tricky cases, so if you run into any issues, check here on how to switch back to the previous solution.
We’d like to remind you that if you experience an IDE freeze or a high CPU/memory usage, the IDE logs, thread dumps and CPU/memory snapshots are required to investigate the issue (here’s how to retrieve them). We would also greatly appreciate it if you collected them on the latest available CLion version.
Project models
Gradle and compilation database
This release makes CLion available for those who don’t have a CMake project, but would like to use the IDE for C/C++ development and take advantage of its full code insight capabilities.
Previously, you could only open a non-CMake folder in CLion and get limited IDE functionality for such projects. (Though to be fair, we should mention that a third-party plugin for Bazel has been available for quite some time.)
Now you have two additional options – new Gradle C++ projects and compilation database. Both provide full code insight in CLion, though with a compilation database you currently cannot build or run the project (as the model simply lacks the information this requires).
To open the project:
- For Gradle: open the build.gradle file from the project sources (note that CLion currently support only new Gradle C++ plugins; the old style won’t work).
- For compilation database: use the compile_commands.json file (see this list of ways to get a compilation database for your project).
CLion will show you the status of the project loading in a Build tool window:
And there you have it! CLion’s code insight, including code completion, code navigation, refactoring, and code analysis, is now fully available for your Gradle or compilation database project. By the way, this means that for example Makefiles and Ninja projects can now be opened in CLion – just generate a compilation database for them and go!
CMake support
As CMake remains the project model that’s most deeply integrated into CLion, we’ve given it a few helpful enhancements. The most important change is that as of today, you no longer need to list header files directly in CMake to get full code insight for such files in CLion. If you include the header or source file into any project file, the IDE will automatically treat it as a project file as well, which means full code insight will work in there!
Note: this works only if the header and source files you include are located under the project root (to avoid changes to your libraries and files when refactoring and so on).
Besides, now when you configure your external tools in CLion, you can use CMake-specific macros to get CMake-specific values like executable name, generation folder, etc.
New tools
We added Valgrind Memcheck support back in v2017.3 as a first step towards tools for dynamic analysis in CLion. In v2018.2, it’s now possible to export/import Valgrind Memcheck results in CLion.
This release also introduces support for Google Sanitizers. Unlike Valgrind, sanitizers require project recompilation with the -fsanitize build flag, so you have to provide it manually in your CMake script, for example: set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=thread -fPIE -pie -g"). For Clang >= 3.8.0 and GCC >= 5.0.0, CLion then detects the sanitizer flag automatically and visualizes the sanitizers output on the “Sanitizer” tab in the run tool window:
See the list of supported sanitizers and the available settings in our blog post.
We’ve run a short survey on Twitter recently, asking developers if they often work with Databases when developing their C/C++ projects. It seems the answer is yes, they do! Therefore, another set of added tools that are worth mentioning are database tools and SQL support. These capabilities join CLion 2018.2 as a bundled plugin, which adds DataGrip’s functionality to the IDE. The list of supported databases is quite impressive and includes MySQL, PostgreSQL, Oracle, DB2, Sybase, and others. In addition to various options to browse and modify database content, the plugin also provide full code insight for SQL.
Debugger
CLion 2018.2 comes with bundled LLDB v6.0 on macOS and Linux. It provides GDB v8.1 on Linux and Windows and GDB v8.0.1 on macOS.
Integration with GDB has been improved on all platforms and now CLion uses pretty-printers of a type to display pointers of that type:
As for LLDB, CLion now treats unsigned char correctly in the debugger, and correctly displays unordered_map:
Recompile a single file
A small but neat feature was added to speed up your development cycles in CLion when working with CMake or compilation database projects. Now you can recompile a single file without triggering the full project recompilation. This is really handy for checking local files changes:
Learn how it works in detail by reading this blog post.
And more
There are more changes in this release than can fit into this blog post that’s already long enough (if you’re still reading this – thanks!). At the very least we must mention the latest IntelliJ Platform goodies, including MacBook Touch Bar support and a few VCS support enhancements.
Try these new features by downloading CLion 2018.2 and starting your 30-day free evaluation. By the way, you can use this demo project from GitHub to check out some of the enhancements. Do give us your feedback, too!
Your CLion Team
JetBrains
The Drive to Develop
Subscribe to CLion Blog updates
