News

CLion 2016.3 released: Modern C and C++ support, remote debug on Windows, CMake workflow changes and more

Great news: As of today, CLion 2016.3 is generally available!

clion2016_3_506x253_2x

In its third and final update this year, our cross-platform C/C++ IDE gets a firmer handle on modern language standards, incorporates top-voted changes in working with CMake project model, and brings lots of other enhancements. Take a closer look at these and other capabilities available in CLion 2016.3:

Download CLion 2016.3

C++ language support

With C++ evolving quickly, it’s crucial for an IDE to support modern standards. While relying on our own parser, we do our best to catch up. Version 2016.3 brings lots of improvements for C++11 and C++14.

User-defined literals

First, we’ve introduced support for user-defined literals. This concept of the built-in type that you can define based on integer, float, character, and string literals by adding special suffixes, became especially popular after it was included in std::chrono (as well as some other places in the Standard Library). CLion 2016.3 is not only aware of the syntax, keeping code with user-defined literals away from false-positives in code analysis, but it also understands the type and shows it in the Quick Documentation popup (Ctrl+Q on Lin/Win, F1 on macOS):
udl_type
It also allows you to rename such literals:
udl_rename

Overload resolution improvements

In order to make CLion’s code analysis more accurate, we’ve improved our overload resolution support, which eliminates lots of false-positives. You can now catch two problems on the fly in the editor, thanks to the new code inspections:

  • Ambiguous call
  • No matching function to call

ovr

Code analysis accuracy

Static analysis in CLion helps you catch problems on the fly and write beautiful and correct code more easily. CLion 2016.3 introduced some important fixes for:

  • Reference may be null checks for one-element initializer list case;
  • Loop variable is not updated inside the loop warnings;
  • Simplify quick-fix for overloaded operators;
  • Unused variable in case of non-trivial destructors (including a fix for for the so called ‘guard’ idiom);
  • Platform-dependent sizeof()-related analysis;
  • Local variable is never used check inside the sizeof() expressions;
  • Code analysis check for bitwise shift operators.

It also provides support for __attribute__(unused) and __builtin_unreachable.

C++14 digit separator

The last but not the least, is C++14 digit separator support. Not that much to say here except that it now works, but it does mean that we are open now to C++14 fixes and will look at it more closely soon. So if you have something in mind from C++14 that really annoys you in CLion, let us know.
digit_separator
Current list of supported features sorted by standard can be found in our webhelp.

C language support

CLion is an IDE for both C++ and C, so we’ve put our efforts in C language support as well, including _Generic keyword support and completion for specific C11 keywords such as _Thread_local, _Alignas, _Noreturn, _Static_assert, and _Atomic:
c11_completion

CLion 2016.3 also introduces support for gcc atomic builtins:
atomic_builtin

By the way, you may remember that we promised C and C++ project templates in 2016.3. Unfortunately, they are not ready yet, but will definitely make their way to one of the 2016.3.x updates a bit later. Stay tuned!

Remote debug

CLion 2016.2 introduced remote GDB debug feature for Linux and macOS. This included connecting from CLion on Linux or macOS to the application running remotely on Linux machine under gdbserver.
With 2016.3 the feature is enabled on Windows as well. Use it to debug applications run under gdbserver on remote Linux or Windows machines. Find more details about cross-platform debug in this case here.

CMake workflow changes

CMake is a core technology for CLion as it’s the project model and the whole IDE relies on it heavily. While we still consider adding other build systems support (i.e. Makefiles, autotools, qmake), we want first to finalize the approach CLion takes when working with the project model. With the previous solution, our users have complained about:

  • high memory usage,
  • useless configurations building,
  • performance issues, and
  • restrictions on CMake generation directory configuration.

To incorporate your suggestions and solve the above problems, we’ve come up with a new approach in CLion 2016.3.

In a nutshell, CLion now builds only one selected configuration and allows setting the CMake generation directory. That also makes it possible to open projects from an already existing CMake generation folder without additional generation (right now this only works for Makefiles generator) – just point to a generation folder or CMakeCache.txt file:
open_existing_cmake

There are also CMake output logs available in the CMake tool window, and the ability to add variables to CMake Cache. Read more details in this blog post.

While the changes have been released, we are still working on this and will roll out a couple of improvements in the upcoming updates and next versions:

  • Allow configuring defaults for the CMake settings (CPP-1887).
  • Find existing generation folder and suggest to use it when opening CMake projects (CPP-7943).
  • Allow additional generated build types (CPP-3159).

Let us know what you think about the changes in the comments below and in related issues in the tracker.

Resolve context

Consider the situation when some source or header file is used for several CMake targets, and their sets of variables and flags differ. It could happen that in your editor, code highlighting, find usages, refactorings, code generation and code analysis all depend on these variables and flags. How should an IDE deal with this situation? We believe that the correct way is to take into account the build/run configuration selected (that actually complies with the CMake target).

Since version 1.0, CLion has allowed using a special resolve configuration switcher in the bottom right-hand corner of the editor:
resolve_switcher

However, in version 2016.3 we made it possible for CLion to switch the resolve context automatically when the user changes the build/run configuration. This makes the whole experience nicer and more comfortable. You don’t have to think about these things as the IDE does it for you. Isn’t that great?
switch_context

If you still prefer the manual switcher, feel free to use it. However, be aware that automatic switching will then be disabled until the IDE restarts.

Semantic highlighting

When you read code, wouldn’t it be great to see how the data flows through the code at a glance? Highlighting each variable/parameter with its own color appears to be possible solution. That’s where the idea of semantic highlighting comes from.

Many of you have asked us about this feature in CLion, and today we are glad to say it’s available in CLion 2016.3. Three simple rules are used to highlight the code:

  • Each parameter and local variable has its own color.
  • CLion tries to keep colors unique inside the body of a function or lambda.
  • Identifiers with the same name are assigned the same color.

semantic_highlighting
Go to Editor | Color & Fonts | Language Defaults to enable Semantic highlighting in CLion.

Improvements for UE4 projects

Games created with Unreal Engine 4 can be developed with CLion. However, previously it took quite some effort to get a CMake project for UE4 game ready. With a third-party plugin for Unreal Engine, CLionSourceCodeAccess, that task becomes a lot easier.

Another plugin made by one of our team members, Unreal Engine 4 SDK Support, can speed up your game development by adding extra completion options for UE4 reflection specifiers, which CLion is unable to provide by default:
ue4

We’ve also introduced significant performance improvements for re-opening projects that have already been indexed once in CLion.

Here’s a good read if you’re interested in developing UE4 games in CLion.

Doxygen

Templates are the cornerstone of modern C++, and we believe IDEs should treat them specially.

CLion’s Doxygen support includes generation of documentation stubs for types and functions that have parameters, return a value or throw an exception. If there are template parameters in a function, class or structure, CLion 2016.3 will generate a stub that includes the tparam tag:
tparam_gen

In addition, the Rename refactoring for such a parameter updates the documentation comment.

VCS

Like all IntelliJ-based IDEs, CLion 2016.3 comes with a set of improvements for Version Control Systems support:

  • Undo actions for the last change that you haven’t pushed yet, and the ability to restore a deleted local branch.
  • Git Sign-off commits possibility.
  • Ability to resolve simple conflicts in one click (nonoverlapping changes on one line):
    resolve_conflict
  • Performance improvements for filtering in Git and Mercurial log, as well as some nice UI polishing.

Other changes

Among other fixes worth mentioning is the Find in Path dialog, which now keeps previously used settings (scope, file name filter, context, etc.) regardless of where you call it from. This can be helpful when doing subsequent searches through the various folders in the project:
find_in_path

To play with the new features, check our special repository that we maintain in order to illustrate changes in CLion 2016.3 in a very code-centric way.

Check out this short demo to see new features in action:

https://youtu.be/yL4cbUztDeI

To learn more, please visit the What’s new in CLion 2016.3 page on our website, view our demo and download CLion for your operating system:

Download CLion 2016.3

Your feedback is very welcome in the comments section below!

Your CLion Team

JetBrains
The Drive to Develop

Discover more