CLion 2017.3 released with C++ support improvements, Valgrind Memcheck, Boost.Test and much more

Please welcome CLion 2017.3!

This year’s third release of CLion managed to accomplish both missions – bring dozens of C++ language support fixes, and overhaul and integrate new tools like Boost.Test and Valgrind Memcheck. Besides, v2017.3 updates a number of bundled tools, provides a simpler and more flexible way to configure toolchains, and improves the UI for running/debugging your applications.

CLion 2017.3 released!

Read on for more details and get a free 30-day trial to evaluate all the new features and enhancements:

Or watch this overview video from Phil Nash:

Download CLion 2017.3

C++ language support

Keeping our sights on making our C++ language support more correct than ever, as promised, we’ve started overhauling the key areas, implementing fixes from the bottom way up to the top. The two big areas affected in v2017.3 are list initialization and name lookup.

List initialization

List initialization is a standard way to initialize an object from braced-init-list since C++11. In v2017.3, we’ve reworked the way CLion handles it to avoid many false warnings and errors in code analysis (like “too many arguments”, “too few arguments”, “no matching constructor”, etc.). Among others, this has fixed the resolve for members of auto variables with uniform initialization, incorrect “parameter type mismatch” for boost weak pointer initialization, and invalid warnings for C99 union initializers:

Name lookup

Name lookup is a C++ standard procedure to associate a name with a declaration. In this regard we have improved code analysis, code navigation, and more. The changes affect the resolve of the symbols brought into scope, for example, via class inheritance or a using construct. The fixes also introduced the correct resolve order in several cases where it failed previously:

MSVC extensions

Microsoft Visual C++ compiler is still working in experimental mode in CLion. If you have MSVC installed on your machine, enable the Registry option clion.enable.msvc and switch to MSVC in the Toolchains settings in CLion. You will now see significantly less incorrect code highlighting and fewer false errors from code analysis, as CLion 2017.3 provides support for MSVC extensions. Check the list of supported extensions here.

JUCE support

While these fixes are general, they are mostly noticeable for those who do cross-platform audio development with the JUCE library. The changes affect code analysis and navigation in many situations.
Even though JUCE 5.2 removed include directives inside namespaces, we still think this case is worth covering in general, so CLion 2017.3 supports it and resolves the symbols correctly:
Talking about JUCE a bit more, its v5.2 release brought CLion/CMake exporter support to Projucer, which means it’s now super easy to start developing your audio plugin with CLion. Just check this very short demo where I take a demo Projucer project and debug in CLion this audio plugin running in Ableton Live:

And more

More changes in C++ language support include:

  • Support for C++11 friend declaration syntax
  • Support for the __COUNTER__ macro:
  • Generate Definitions (Ctrl+Shift+D on Linux/Windows, ⇧⌘D on macOS) for function templates
  • New intention action to invert the condition in an if clause and flip its if-else blocks:

Valgrind Memcheck

Dynamic code analyzers are great for catching issues that static code analyzers miss or for finding possible inefficiencies visible only in runtime. The most famous tool sets for dynamic analysis are probably the Valgrind tool family and Google Sanitizers.

As a first step towards providing support for profiling tools, we’ve implemented an integration with Valgrind Memcheck (memory error detector in Valgrind) in CLion 2017.3. The most important benefits this choice are:

  • Valgrind is a famous family of tools and Memcheck is probably the most used one from the whole family
  • Valgrind supports multiple platforms
  • Valgrind doesn’t require a program recompilation and supports both GCC and Clang

Note that Valgrind works only on Linux and macOS, which means these changes are, unfortunately, of no use to Windows users.

Memcheck is capable of catching the following problems:

  • Invalid memory access (for example, accessing memory after free)
  • Usage of the uninitialized (or derived from the uninitialized) values
  • Mismatched malloc/free new/delete operations
  • Overlapping src and dst pointers in memcpy and related functions
  • Incorrect size value passed to the memory allocation functions
  • Memory leaks

Learn how to configure and use Valgrind Memcheck.


Boost.Test, the second most-used unit testing framework for C++, is now available in CLion 2017.3. Using it is similar to using Google Test and Catch frameworks, including special configurations to run Boost.Test and a built-in test runner:

Configuring multiple toolchains and compilers

This release introduces dozens of changes in this area. We’ll summarize them, describe the main use cases, and tell you about the final flow for configuring toolchains.

Toolchains & compiler settings

The main idea behind these changes is to allow you to use different toolchains for different projects in one IDE, or even inside one project for different configurations. Typical cases include:

  • On Windows, use MinGW/Cygwin/Microsoft Visual C++ simultaneously
  • Use different CMake versions
  • Use different Make, C, and C++ compilers
  • Use different debuggers (for example, bundled GDB for one configuration, some specific custom GDB version for another configuration, and LLDB for the third one)

Configure toolchains in Settings/Preferences | Build, Execution, Deployment | Toolchains. The default one takes all system parameters from the platform used. Note that toolchains are configured per IDE (not per project), so you can simply configure all your toolchains there once and use them for all of your projects later.

Toolchains sample configuration on macOS:

Toolchains sample configuration on Windows:

CMake profiles & build type switcher

CMake profiles describe the set of settings used when CMake is run for the current project:

  • Build type (Release, Debug, MinSizeRel, RelWithDebInfo and any custom one)
  • Toolchain to be used (from the list of those configured in Settings/Preferences | Build, Execution, Deployment | Toolchains)
  • CMake options
  • Environment parameters
  • CMake generation path (build output)
  • CMake build options

The changes also make it possible to have several CMake profiles with the same build type but different set of settings, like toolchains for example (this was not the case before this release).

The typical use cases include:

  • Create Debug and Release CMake profiles, and switch between them when running or debugging your application
  • Create one CMake profile with Clang compiler and another with GCC, and switch between them when running or debugging your application
  • On Windows, create MinGW, Cygwin and MSVC toolchains, create 3 CMake profiles using separate toolchain each, and switch between them when running or debugging your application

To switch between CMake profiles, select them in the run configuration switcher on the toolbar. Alternatively, you can select them in the Run/Debug configuration switcher popup, which is opened with Shift+Alt+F10 (Linux/Windows) / ^⌥R (macOS) for Run and with Shift+Alt+F9 (Linux/Windows) / ^⌥D (macOS) for Debug.
Additional notes on the CMake profiles/build type switcher can be found here.

Run icons for main functions and tests

The left gutter in the CLion editor can help navigate your code (for example, navigate to the base/derived class or to the declaration/definition) and show VCS status. Now it’s also helpful for the task of running/debugging your app.
For every main function in your code, as well as for every test (if case you use one of the officially supported frameworks like Google Test, Boost.Test or Catch), CLion shows a run icon in the left gutter. Click it to run, debug or run the corresponding main or test function with Valgrind Memcheck:
For unit tests, these icons also report the status of the tests: success or failure.

And even more!

Other important changes include:

  • Separate settings for function calls and function declarations in Settings/Preferences | Editor | Color Scheme | C/C++
  • Bundled CMake 3.9, GDB 8.0 with multiarch support, LLDB 5.0
  • Various platform changes, including VCS support improvements
  • Kotlin/Native, a brand new technology that compiles Kotlin directly to machine code, is now supported in CLion via plugins

Whew, that’s it! Explore all the new features in even more detail on our website. Start your 30-day free evaluation and try out all these new features and fixes (a demo project to play with).

Download CLion 2017.3

Your CLion Team

The Drive to Develop

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

51 Responses to CLion 2017.3 released with C++ support improvements, Valgrind Memcheck, Boost.Test and much more

  1. Evgenii says:

    Together with Valgrind support, which is really cool, it’d nice to gave Google Sanitizers integration too.

  2. Roman says:

    Congratulations! Great release. Support for multiple toolchains is great, especially for cross-platform libraries where we need to fix various compiler-specific bugs.
    Parsing quality improvement is also quite noticeable. Still there are some bugs in parsing, but they don’t harm productivity in my case.

    My wishlist for 2018:
    1. CTest support. Very important when testing code on different input and with various command line parameters. This area of testing is not covered by unit testing. (It is possible to call std::system from GTest, but then you will need to “attach to process” for debugging)
    2. Better incremental performance (better caching, incremental parsing, etc). Ideally, we should suffer from freezes only once: when opening large project first time.
    3. Debugging support on Windows.
    4. Low-level debugging support: disassembly view, memory view, register view.

    Pipe dream:
    5. Makefile support (Netbeans-like (automatic) )

    • Anastasia Kazakova says:

      Thanks Roman!

      CTest is a probably candidate for 2018. Upvote it here:
      Performance and Debugging improvements are also in plans, I’ll post the roadmap next week probably. We still have some discussions.

      Makefiles could be considered, debugging on Windows for MSVC case is unlikely coming.

      • Roman says:

        I’ve noticed you hired former Netbeans-CPP developer. So you should now have expertise to properly support Makefiles. Nebeans Makefile support is great. Also I think Netbeans had a lot of good ideas in C++ support, my colleagues still prefer it to Clion because of its flexibility. Some of them even hack Linux drivers in Netbeans.

        • Anastasia Kazakova says:

          I’m pretty sure we can benefit from such an expertise, but mind that NetBeans and CLion architectures are different. And CLion’s CMake support is deeper tighten with CMake itself.

  3. Michael lojkovic says:

    Has the most recent version of MSVC supported been updated? Last I checked, a couple of weeks ago, CLion couldn’t find all of the files needed for C++ compilation. Previously the folder I had CLion pointed to for the compiler worked fine.

    • Anastasia Kazakova says:

      VS 2017 should work fine. Do you mean CLion can’t autodetect it and you have to point to the location manually?

  4. hak8or says:

    “Low-level debugging support: disassembly view, memory view, register view.”

    Absolutely. Debugging code running on an embedded platform is much worse than Keil because every time I want to view the assembly I have to go into the GDB command line window, google for what the heck the commands are, type it in, and scroll around. Same with viewing raw memory in Hex or registers.

    While Keil was utterly horrible, it’s debugging situation was better. For example, not only do you have a window which keeps track of what memory you were viewing, it even highlights the bytes of that memory that changed since it was last read.

    But hey, at least I get a real dark theme, CMake support, much better autocomplete, many plugins, fantastic refactoring tools, proper documentation/tooltips of code, and due to CMake can use other toolchains.

    • Anastasia Kazakova says:

      BTW CLion has a disassemble view in case of GDB, but only in case the source code is not available (so for libraries, etc.)

  5. arved says:

    I noticed the handling of adding PATH in the Settings->Environment changed. Previously the original PATH was not overriden but appended(?), with 2017.3 the PATH is overriden.

    In my case this resulted in cmake no longer finding make.

    • Anastasia Kazakova says:

      It was never appended I guess. It works in the same way you do in the console, so you write smth like ‘PATH=$PATH:~/my’ and it appends you ~/my path to the existing value of $PATH

  6. Vadim Peretokin says:

    Excellent! Thanks for this release. By integrating these tools right into the UI, you are helping make them a lot more accessible.

  7. Carlo says:

    Congratulations for the new release! On the roadmap for this version in the “under investigation” list there was “remote development support”. What happened with this feature? As other user pointed out, remote development is really important to make Clion an excellent tool for programmers who develop for more than one OS.

    • Anastasia Kazakova says:

      Yes, the task is in progress now. We started with the WSL (Windows subsystem for Linux) support, and plan to continue with more general configurations and other tasks. You can expect some results in 2018.x releases.

  8. Yaroslav says:

    This release has some serious disadvantages for the embed development.

    As the CMAKE context is now separated from the build configuration it is necessary to choose both run_configuration and CMAKE_context from the combobox synchronously (Due to absence of ability of using placeholders/environment_vars in run/debug configuration it is still necessary to create separate configurations for debug/release)

    – there is no placeholder for chosen CMAKE_context to use it inside run/debug configuration’s [executable], [arguments] and [working directory] fields
    – environment vars which are set in CMAKE settings are accessible from the build process but not accessible in the run/debug dialog and are not passed to possible wrapper as executable.
    – CMAKE_context combo has been removed from run/debug dialog.

    So there is no way to customize run/debug behavior depending on chosen CMAKE_context.

    Also one little bug makes the context switching even more inconvenient:

    • Anastasia Kazakova says:

      > CMAKE_context combo has been removed from run/debug dialog.

      The separation of Build/Run configuration and CMake profiles was done on purpose. 1) It allows to switch build type, compilers, etc. w/o updating Build/Run configuration 2) It will help us in future, when adding more than CMake as a build system on board.

      > there is no placeholder for chosen CMAKE_context to use it inside run/debug configuration’s [executable], [arguments] and [working directory] fields
      Not sure, what you mean here. These values in Run/Debug configuration was never connected with the CMake profiles, as it’s about other things.

      > environment vars which are set in CMAKE settings are accessible from the build process but not accessible in the run/debug dialog and are not passed to possible wrapper as executable.
      This is possibly can be implemented. Could you please describe the use case?

      • Yaroslav says:

        > These values in Run/Debug configuration was never connected with the CMake profiles
        Sure in general they are not connected but in real cases the run configuration can DEPEND on CMAKE context it is being run with. For example when executable is not run directly but by a wrapper. This is a common (or even only possible) approach in a development for embedded systems. So it is necessary to pass somehow path of compiled target to the wrapper. This is possible to achieve by passing a parameter (need a placeholder) or by env. variable.

      • Yaroslav says:

        There is already a 6 year old ticket for IDEA with over 120 votes:
        My wish is to implement a variable (placeholder) for the currently chosen CMAKE context which can be passed as parameter.
        And the ability to define my own variables project-wide/CMAKE_context-specific.

        In general, each field in run/debug configuration should by maximum customizable. Eclipse is a good example: almost each text input can have substitutable variables which are defined in a certain scopes.

    • Roman says:

      Imo, when CTest will be supported, it will be possible to use it instead of run configuration GUI. It has access to CMake variables. Can be used to launch external targets, like python scripts. It is also IDE – independent.

  9. Tano says:

    My most 2 important desires for 2018 (I just renewed my license to 2019 :P)

    1. add the ability to add edit files bigger than 2000 lines.
    Anastatia, I can show you a video by editing a 5000-lines files, I press now and the character appears after 1-2 seconds on the screen.:). No other IDE does that, tested with 5 IDEs.

    2. Keep the old find dialog (the one activated by “”), because the new one still is not perfect (see point 4). I love the old one, it’s perfect, please do not remove it.

    3. Add support for “make install” (CPP-838), a 3-year old request!

    4. IDEA-170662 Increase that mask edit box. Just double its size for the moment if you don’t have time to properly fix it.


    • Tano says:

      2 desires became 4, maybe you add the possibility to edit posts, also :)

    • Tano says:

      @Anastasia, not Anastatia, sorry for misspelled your name in the original post.

    • Tano says:

      Also IDEA-170658 is very very disturbing, there is no way to show in the file mask history only my custom extensions, ctr+space shows all the extensions…

    • Anastasia Kazakova says:

      Let me summarize the comments we already did about these issues and

      1. That’s not a special limitation problem, but a performance issue/UI freeze that was captured in your snapshot. We are working on it in the context of:

      2. We plan to work on the new dialog and proceed with it, as most users are happier with the new edition. But I agree some critical issues have to be addressed.

      3. We have this task on our radar, but I can’t promise you an estimation. What do you expect here btw? A button that executes the command? What configuration is necessary for it from your point of view?

      4. We plan to make an expandable field there. Most likely it will come in some 2017.3.x update.

      • Tano says:

        Thanks a lot for your answers, Anastasia.

        2. Yes, the new dialog is very nice but it has some problems, I am still using the old one because the new one has problems (I found a 2 problems in 5 minutes yesterday when wanting to try the new one – CPP-11390 and CPP-11396), so I reverted back. Therefore I kindly ask you to keep the old one also. The fact that there is no dropbox anymore (is replaced by a “smart” edit box, which is not so smart) causes a lot of problems.
        I want to see the masks history, I have to go to the editbox with mouse, then press “home” (because of CPP-11396) then press ctr+space(keyboard), then select with mouse (see my bug).
        Please try to understand that in the old version it was a dropbox arrow, mouse-click and that was all, it worked.

        This is very silly: mouse,keyboard, keyboard then again mouse. Is there a possibility to use the mouse only for the drop down, for example?

        3. I just want this to be fixed: Again, CLion is the only IDE that prints incorrectly the build output.If I do the exact modification in Eclipse, the output is ok.

        Thanks again.

      • Tano says:

        2. I agree that the new “Find in paths” looks more nice and I really like it also, but is not very intuitive for everyone. For users who search only in 2-3 types of files everytime it is perfect, but I have at least 10 file types in my project and I always switch them in combinations and the switch is very annoying because of that silly (I meant smart” :P) editbox instead of dropbox.
        The window is very very nice, the edit box is the problem.:)

  10. Henry Borchers says:

    I’m curious about why MSVC debugging is a challenge. Is it a licensing issue or just not really a priority?

    Normally, I wouldn’t care so much. However, I recently found that I’ve had to write a number of C and C++ extensions for Python that works on Windows. The official distribution of CPython on Windows is MSVC which limits what I can do on CLion.

    I’m guessing that an edge case so I’m not demanding anything, Anyways, I have found a workflow around this limitation. I’m just curious why add MSVC support but without access to the debugger.

    • Anastasia Kazakova says:

      We can’t bundle or reuse Microsoft debugger (because of the license), as for the other options we need to implement lots of pretty printers and do a big integration work.

    • Jakub says:

      Even in VS Code they have started with GDB because CDB is much harder to integrate.

  11. Jakub says:

    I’m personally quite happy with the separation of toolchains, build types, and targets – it make my life much easier.

    Now, if you could loo into less awkward support for CMake superbuild pattern, I’d be delighted ;).

  12. Sebastian says:

    Support for target_sources in CMake would be really great. I have started to use target_sources for most of my projects now. I usually structure my project into multiple subfolders and place a CMakeLists.txt into each subfolder. In each CMakeLists.txt I use target_sources to add only the files of that folder.

    What I would like to see is that CLion can understand the usage of target_sources and that when I add a new file to a subfolder that it finds the target_sources invocation that is closest to the added file in the hierarchy of CMakeLists.txt

  13. Thomas says:

    Are you considering adding visual studio debugging (msvc compiler debugging)? One of the greatest features of all JetBrains IDEs is the Evaluate Expressions REPL, and I would love to code c++ for windows while taking advantage of that, even though I realize that it will be more restricted than e.g. REPL bundled with IDEs for interpreted languages like python.

  14. Victor says:

    Afraid I’ll have to add a pinch of salt here. I wish I could praise the release but I couldn’t since I had to roll back and return to 2017.2.3. Afraid the performance issues related to large projects are back in full force with 2017.3 to the extent that i couldn’t use it anymore. And believe me I’m not easily scared by lagging UIs. But when a simple ‘Go to Declaration’ might take over a minute (btw going to the declaration via search of the symbol name is reasonably quick) it is a bit difficult to justify using it. And that’s on top of almost doubled memory usage. All in all I’m back to the previous version. Hope you will address the performance issues in the next increment.

    • Anastasia Kazakova says:

      Could you please submit an issue to the tracker with CPU and memory snapshots? Otherwise, it’s hard to catch and fix. Thanks and sorry for the inconvenience.

  15. Esther says:

    Love the new valgrind tool :)
    But after updating to 2017.3 my Cmake is complaining that it can not find my std=c++14 version anymore.. Any suggestion why that might happened? Or how to fix this. Appreciate the help.

    • Anastasia Kazakova says:

      Do you use bundled CMake or some installed separately on your machine. Which version does it have?

Leave a Reply

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