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.

800x400_blog@2x

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:

For a quick overview of the new features and enhancements, watch this video from Phil Nash:

Download CLion 2018.2

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:
clangd_settings

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?
wrong_arguments_inspection
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:
gradle_build

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).
cmake_project

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:
sanitizers

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:
gdb_debug_view

As for LLDB, CLion now treats unsigned char correctly in the debugger, and correctly displays unordered_map:
lldb_fixes

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:
recompile

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!

Download CLion 2018.2

Your CLion Team

JetBrains
The Drive to Develop

This entry was posted in Announcement and tagged , , , , , , . Bookmark the permalink.

56 Responses to CLion 2018.2 released: clangd, Gradle and compilation database projects, Google Sanitizers, and database support

  1. Roman Popov says:

    Congratulations with fantastic release! Great improvement in performance and freeze reduction, finally Clion works fast enough on large projects.

    clangd integration is also great. No more red code. Most syntax errors are highlighted immediately when coding (almost all, except for CPP-13484)

    With compilation database support I can finally work on Makefile projects in Clion.

  2. Tano says:

    It seems that IDEA-184743 did not make it this release either, it’s just replacing a string, 20 seconds job…
    Besides that, CLion is still improving, which is a great thing.

    • Anastasia Kazakova says:

      We are sorry it’s not done, but I hope you understand developers have hundreds of issues, and a more priority will come to the new-style dialog that is a default one for now. I’m not even sure we’ll maintain the old one for a long time. But I’ll check with the developer if he can update the button shortly.

  3. Tano says:

    I had clangd disabled in 2018.2 EAP and after upgrading to 2018.2 the clangd is enabled, as I expected, that’s why I checked..
    I really hate when new CLion overwrites my settings.

    • Anastasia Kazakova says:

      Why have you disabled it? Any issues with it? We forced the enabling on purpose in this situation.

      • Kirill Sapozhnikov says:

        I disabled it too because it works slower then default error engine. It’s strange because it seems to me that it worked faster when it was first introduced in one of EAPs

        • Anastasia Kazakova says:

          Hm, why do you think it’s slower? How do you decide that?

          • Kirill Sapozhnikov says:

            1) It just SEEMS to me that it is slower then EAP. I didn’t make any measurements but for my project it seems so.
            2) clangd is definitely slower then default error engine in this situation:
            I currently refactor old legacy code that contains more than 500 global variables. When I copy paste some function to the new class method there are about 20-50 unresolved variables that are marked red. If I add one variable as a class field with clangd it can take about half a minute to unred the variable. With old error engine it happens almost instantly.

            My platform is Linux Mint Mate 18.3

          • Anastasia Kazakova says:

            Could you please tell us how long it takes the compiler to compile the file where you experience a performance degradation with clangd?

        • Anastasia Kazakova says:

          Also what platform are you on?

          • Kirill Sapozhnikov says:

            Compile time for this file. Replying here because can’t reply to original request.

            real 0m1.254s
            user 0m1.160s
            sys 0m0.084s

  4. Kirill Sapozhnikov says:

    Thanks for release.
    Unfortunately it brings new bugs that I can’t report because they are reproducible only with specific project. And total resolving time seems slower. Hope upcoming bug fixes will improve situation like they did with 2018.1

    • Anastasia Kazakova says:

      We haven’t observed any resolve time slowdowns. Some information for investigation is necessary.

      • Anastasia Kazakova says:

        Could you please do the following: enable clion.clang.clangd.debug in Registry, open a couple files with clangd and send us the resulting idea.log (it might contain users’s source code in this case)?

        • Kirill Sapozhnikov says:

          I can’t do that if it contains source code. Not with the particular part I’m currently wotking with. I’ll definitely try this when I’m back at work tomorrow but I cant guarantee any feedback. I understand that you cant do anything certain without it

          • Anastasia Kazakova says:

            Regarding this sensitive log – there is a dump of the JSON messages sent to/from clangd, so it naturally contain source code of the opened files. You can remove it manually, leaving the rest of the info.

        • Kirill Sapozhnikov says:

          Created CPP-13787

    • Roman says:

      Actually I have same feeling, like clangd in EAP was working faster. But I can’t prove this :)

      • Anastasia Kazakova says:

        We don’t see any reason why this could happen… But in general, the performance improvements for clangd will be a part of our plans in future for sure

  5. Roman says:

    Hm, unordered_map is not pretty-printed in LLDB on my machine. Do you support GNU libstdc++?

  6. Liwei says:

    Today, I am glad to upgrade my CLion to 2018.2, only to find up to 23 errors in one of my header files. Disable clangd in “show errors and warnings from clangd”, and all these errors disappeared. I don’t know if DEVs know these bugs. It make me feel lazy to report all these bugs.

    P.S. Having joined CLion from 2017.1, I’m happy that the performance has really improved a lot. In the old days, I often have to wait minutes until CLion becomes responsive. CLion is becoming better and better.

    • Anastasia Kazakova says:

      Is it errors or Clang-tidy warnings?
      Which platform are you on? What’s your regular compiler? Can you share your code with us?

    • Anastasia Kazakova says:

      Another guess here: do you have a header guard in this header?

      • Liwei says:

        I have reproduced these bugs in a simpler way: CPP-13791, CPP-13792. Maybe these two are the same problem. Because this problem locates in my header file, so almost all my project files are affected. (Classes are regarded as unknown names because class members are known. And this unknown name error infects their child classes.)

  7. ice1000 says:

    Please fix CPP-13600 it’s annoying.

    And I’m curious about why is CPP-13578 happening, could anyone explain a little bit? I can’t understand why is it happening.

    • Anastasia Kazakova says:

      I guess the only possible explanation is that it’s a bug.

      Thanks for pointing this out. We’ll check.

  8. Lyosha12 says:

    On my latest Windows 10 Pro this CLion 2018.2 has crashed while it idle (or not). Crashes are regularry, so I rolled to 2018.1.6. If I can help to detect this problem say me how.

  9. CLion says:

    The CLion 2018.2 roadmap included the item “Implement first prototype for remote development support, limit target system to Linux, other limitations are possible”.
    Is it out in this version?
    If the answer is no, then when is it expected?

    Thank you.

    • Anastasia Kazakova says:

      It’s in progress (in development), it wasn’t ready to share in the public build but we expect it to be ready for 2018.3

  10. Anton Rapetov says:

    Hi, some of the new features looks good, however, due to https://youtrack.jetbrains.com/issue/CPP-12181, I can’t update from CLion 2017. Can I ask when CPP-12181 and https://youtrack.jetbrains.com/issue/CPP-12180 issues are going to be fixed?

    • Anastasia Kazakova says:

      Hrm, seems like that has escaped out attention. Sorry about that. We’ll check and update in the tracker.

  11. Mike says:

    The out-of-order inspection triggered for me today (on day 1 of using 2018.2) and caught me from a bug that certainly would have bitten me later. CLion paid for itself yet again!

    WSL support is also much improved (I can finally move to Ubuntu 18.04).

    Great job!

  12. Victor says:

    This is a second release, the first one was 2018.1, which I try for a day and then return to 2017.2.3. Had I paid for standalone CLion only I would have cancelled and requested refund by now.
    See I would have genuinely appreciate the effort you put into extending the feature set had it not been affecting the performance of the basic functionality.
    You should seriously consider feature freeze and release a version with performance fixed. If basic navigation through the code is not snappy and from time to time freezes IDE for a minute or more I won’t care about new inspections. If a simple refactoring (rename) has a chance of freezing IDE to a state that i need to kill IDE manually, I’m sorry, I will not give a damn about the new tools support.The list might be continued on and on…
    All in all in the current state and form the release is not suitable for enterprise size applications ( that is of course is my personal opinion based on the few codebases I work with and the feedback from my colleagues).

    • Anastasia Kazakova says:

      We are sorry to hear that. IDE performance is our top priority and a huge work is being done in this direction. This release includes a bunch of related fixes. Others are still in plans and on our radar. Maybe you can point to some particular issues in our tracker so that we check where they are in our plans? Thanks

      • Victor says:

        Just a few from memory as I’ve already uninstalled it:
        – ‘Go to declaration’ on a symbol might take from few seconds to over a minute. That said using a symbol search dialog always produced acceptable quick results
        – ‘navigate related symbol’
        – Refactor -> Rename . I might have been unlucky but few attempts i’ve made frozen the ide dead – even for function local variables.
        – Quite a few occurrences of a short freeze and I believe a popup saying something like ‘preparing arguments list’ or something of the kind when typing and reaching argument list of called function
        – same long standing issue for IDE grinding to a halt in presence of number of complicated macros.

        • Anastasia Kazakova says:

          Have you shared the CPU snapshots with us for these issues? Or a thread dumps generated automatically on freezes?
          Some of these things were fixed in 2018.2, but maybe on your project some other issues are causing these slow downs. Snapshots/dumps might be useful.

  13. Roman says:

    Interestingly, what is considered to be an “enterprise size application”? I have a project with 1.9 million source lines of code and performance is reasonable in 2018.2 (and way better then in 2017.2).
    The only action that freezes IDE for me is switch between header/source (navigate related symbol).

    • Victor says:

      “enterprise size application” could have been an unlucky name I’ve chosen. The size of a code base is just one aspect of systems I meant. Loads of legacy code mixed with newer additions, large number of 3rd party dependencies with some being quite old and in overall dozens or sometimes even hundreds of devs who coded something in over the life time. Those are just a few things which make,say, navigation/refactoring are essential for working with codebase. And that’s where I believe shortcomings of this product are.
      As for your example, a positive result doesn’t prove absence of a problem. A negative one on other hand does indicate a presence of such.

  14. Helge Penne says:

    This seems much less likely to freeze than 2018.1, which is good.
    However, there are some regressions like CPP-11124. Can we please get a fix for this in 2018.2.1?
    Also, the regression CPP-13330 was reported during the EAP but no work seems to have been done to fix it. Can you please fix this as well. You really should prioritize regression bugs reported during EAPs…

    • Anastasia Kazakova says:

      CPP-11124 is not a regression, it’s an issue that is present for a while and is in our “fixing freezes” plan for the upcoming versions. By the way, if you experience this freeze, could you please collect fresh dumps from 2018.2 version and attach to the ticket? We would appreciate it very much.

      As for CPP-13330 – it’s currently under investigation/discussion. We’ll update in the issue.

      We definitely prioritize regressions, but often (especially when we talk about freezes) this is not a regression, but just a bug that was hidden behind another one that’s fixed now. But thanks for pinging us! We’ll check both and see if we can backport the fixes to some 2018.2.x.

      • Helge Penne says:

        Thank you. I’ve uploaded dump files to CPP-11124.

        By the way, if it is possible to fix CPP-13885 then that would be much appreciated too. Generally, all that bugs that are freezes and/or ruin the programmers basic workflow are very important, much more so than new advenced features. There are still a few left, although things have improved in 2018.2 relative to 2018.1 (which was perhaps not your best release).

        • Anastasia Kazakova says:

          Thank you.

          We are constantly working on UI freezes and have a huge plan how to deal with them. All the issues in our tracker are in this plan. And we are fixing them step by step with each release. So you can expect more improvements in 2018.3

        • Anastasia Kazakova says:

          BTW, don’t see your dumps in CPP-11124. Have you attached to the issue itself or uploaded to FTP?

          • Helge Penne says:

            Ah. I wrote CPP-11124, when I should in fact have written CPP-13892. Please accept my apologies for the confusion.

            I ended up creating a new bug entry as I suspected that what I was seeing was not a duplicate of CPP-11124 after all. The freeze happens only when using Find Usages during a build, while CPP-11124 is more generic and could well have a different cause. I suspect CPP-13892 is in fact a regression. Please have a look. The dump files are in CPP-13892.

          • Anastasia Kazakova says:

            Find Usages action is currently in process of fixing many UI freezes. Hopefully will be improved in 2018.3

  15. BSD says:

    No support Qt?

  16. lmiguelmh says:

    Using PLOG (https://github.com/SergiusTheBest/plog) macros (LOGD, LOGI, LOGE) makes CLion marking the line erronously as “Expected expression”.

Leave a Reply

Your email address will not be published. Required fields are marked *