November 23, 2016 at 17:08CLion 2016.3 release: improved support for C11, C ++ 11 and C ++ 14, changes in working with the CMake project model and much more
Hello, Habr! The year is slowly coming to an end, someone is already preparing for the festivities, and someone else is trying to complete everything conceived. And here we have released the third release of our cross-platform IDE for development in C and C ++ this year . Looking back (and summing up, as is customary to do on the eve of the new year), it seems to us that in 2016 CLion has grown significantly and become much more mature:
We tried to listen to our users (as far as possible) and focus on their requests. Version 2016.3 was no exception and brought many long-awaited improvements:
And now, first things first.
As you probably know (after all, they ask us in the comments under each post about CLion), in CLion we rely on our parser , and active work on it does not stop for a minute. This time, several significant improvements are worth noting.
The first is the support for custom literals . We did not take up this task for a long time, but the growing popularity of the concept of the built-in type and the appearance of its use in std :: chrono and other parts of the standard library led us to the need for its support. It is worth noting that in addition to reducing the number of false-positive errors of the code analyzer (which were caused by the lack of support for user literals) and the Quick Documentation pop-up window (
Since we are talking about operators, it is worth noting that CLion can now look for cases of using overloaded operators (except for new and delete), which can be especially useful when meeting new and unknown code that actively uses this feature of the language:
Another reason for multiple errors of the built-in code analyzer that was fixed in this release is fixes in support of overload resolution. Now CLion can choose the right candidate correctly, which means that it will correctly show the unused code, find all uses, rename the function or change its signature, etc. And along with this, the development environment will now point you to an ambiguous call or the lack of a suitable function to call - the appropriate inspections were added in CLion 2016.3:
In general, our team has expanded, and in particular, we have more people involved in code analysis. Thanks to this release 2016.3 brought many changes in this area. For example, analysis that relies on sizeof () calculations has become platform dependent. We also corrected an erroneous warning about an unused variable in the case of a nontrivial destructor (which is especially important for the so-called ' guard ' idiom):
In addition, CLion now understands and correctly considers __attribute __ (unused) and __builtin_unreachable when analyzing the code. And these are just a few of the many static code analysis enhancements that came in CLion 2016.3.
An important step in the further development of language support can be considered the emergence of support for the separator characters (C ++ 14). We hope that in the future we will be able to devote time to other possibilities of the latest C ++ language standards. If you want to draw our attention to something specific, we recommend that you vote for the appropriate tasks in our tracker .
Our users quite reasonably noticed that support for pure C in CLion is a little lame. We finally decided to fix this and added support for gcc atomic builtins and the _Generic keyword , and for the keywords _Thread_local , _Alignas , _Noreturn , _Static_assert , and _Atomic , which appeared in updates to version 2016.2, this version added auto-completion to speed up the writing process code:
Someone here may recall that in this version it was planned to add project templates, in particular for the C project. We are forced to honestly admit that the work is ongoing, but not yet completed. But already in one of the upcoming updates 2016.3.x templates will appear.
These changes were preceded by a lot of controversy and discussion. Unfortunately, our initial approach did not suit many. Objective criticism was actively accumulating in the tracker. For example, a request to change the directory in which CMake is generated collected ~ 90 votes and ~ 90 comments. On a blog, on Twitter, live at a variety of conferences and exhibitions, we have repeatedly discussed performance problems caused by the fact that CLion collected all four CMake configurations for each project (Debug, Release, RelWithDebInfo, MinSizeRel). And finally, in version 2016.3, we substantially reworked the approach and proposed a solution to the accumulated problems.
Now CLion collects only the selected configuration . This setting, as well as the path to the directory where you want to generate, is in the dialog of design settings Build, Execution, Deployment | CMake By default, the project is built in a directory inside the project source code named cmake-build-debug . In the future, we plan to enable users to change the default values (for example, to specify the directory for the assembly common to all your projects).
Thanks to these changes, it was also possible to open the project from the directory where CMake was already generated without calling CMake again, which significantly saves time opening the project. To open a project, it is enough to specify the assembly directory or the CMakeCache.txt file:
Please note that this only works if Makefiles were used as a generator. Otherwise, CLion will cause CMake regeneration.
CMake, as you know, the system is not the easiest, especially for beginners. To simplify the debugging of CMake scripts, we added the ability to see the logs of invoking the CMake command in the CMake window. But the CMake Cache editor has been removed. Instead, the development environment opens the CMakeCache.txt file directly in the editor, which makes it easy to add new values. In future releases, we plan to teach CLion the “language” of CMake Cache files to make working with them faster and more convenient.
In the last release, we added the ability to debug from CLion applications running on a remote machine from under the GDB server. True, not all combinations of local and remote platforms were available. The release of 2016.3 brought the ability to remotely debug from the Windows platform:
By the way, in addition to remote debugging, a lot of corrections have occurred in the debugger. So, for example, CLion no longer overwrites the PYTHONPATH environment variable , which in particular allows you to debug C extensions for Python (Python C extension modules).
Another long-awaited feature is semantic highlighting! I’ll say right away how to turn it on: go to the Editor | Color & Fonts | Language Defaults, find the Semantic highlighting group there and check the Unique color for each parameter and local variable checkbox . Further, you can adjust the color ranges as you wish, or use the default values.
Semantic highlighting is designed to better understand how the data flow changes during the execution of your program. To do this, all variables and parameters are painted (if possible) in different colors.
How it works in CLion:
Well, it looks something like this:
Another change related to code highlighting is the automatic switching of the resolve context in the editor when changing the configuration. Let's see why this might be necessary.
Imagine a situation where a source file is included in the assembly of two different CMake targets. At the same time, the settings for these targets are different, and in the code itself there are conditional compilation blocks depending on these settings. What about the code editor in this situation? How to correctly highlight these parts of the code, how to look for cases of use, how to produce the correct code refactoring? The answer is simple: select the settings of a single target and use them. But which one? It seems logical to us that the one you are working on now and which you are collecting / debugging at a given time. Therefore, when switching the Run / Debug configuration, CLion 2016.3 automatically switches the resolve context for the file:
If nevertheless this is not what you want, use the manual switching of the resolve context in the lower right corner of the editor. Automatic switching in this case will be disabled until the next restart of the IDE (but this is more a bug than a feature).
Here on Habré there were already several discussions of game development using Unreal Engine in CLion. As part of this release, we decided to see how we can help users in this case. And the reason was the emergence of a third-party plug-in for Unreal Engine, which allows you to open a project in CLion, generating the necessary CMake scripts for it. We tried this plugin and were pleasantly surprised by the fact that the resulting CMake allows CLion to index the project faster, since it does not include all the source codes of the game engine, but only the necessary part.
Having rejoiced, we significantly reduced the time for re-opening the already indexed project in CLion. Our colleague also added a plugin.for autocompletion of reflection specifiers:
A detailed post on how to develop games based on Unreal Engine in CLion can be read on our blog .
There are many other changes and corrections in the release of CLion 2016.3, but in order not to delay, we will mention them only briefly:
Below is a short demo in English from Phil Nash, our development lawyer:
In general, if you are interested and want to try the new version, as usual, there is a 30-day free trial , and in the price section you can find out about the cost of the subscription.
Stay tuned for articles and updates on our English-language blog . We will be happy to answer any of your questions in the comments.
Your JetBrains CLion
The Drive to Develop Team
- As in terms of language support (variadic templates, auto-import and just numerous corrections in terms of code analysis),
- So in terms of various features that increase development productivity (new code generation options, complete statement, refactoring in CMake),
- New languages (Python, Swift),
- And, of course, the tools associated with developing in C and C ++ (remote debugging and debugging of processes that are not running from the IDE on the local machine, support for the Doxygen code documentation format, many improvements in working with version control systems).
We tried to listen to our users (as far as possible) and focus on their requests. Version 2016.3 was no exception and brought many long-awaited improvements:
- Besides the missing features of C ++ 11, we were finally able to start supporting the capabilities of the C ++ 14 and C11 standards.
- The redesigned approach to working with the CMake project model solved many difficulties that our users faced (from the inability to change the directory in which CMake generation runs, to performance and memory consumption problems).
- Remote debugging is now possible on the Windows platform.
- The editor has a semantic highlight.
- Improved performance when re-indexing projects based on Unreal Engine, and we also examined the current state of a third-party plug-in for generating CMake for projects on UE4 and wrote a whole separate post about it .
- Many other improvements and changes.
And now, first things first.
C ++ Support: C ++ 11 and C ++ 14
As you probably know (after all, they ask us in the comments under each post about CLion), in CLion we rely on our parser , and active work on it does not stop for a minute. This time, several significant improvements are worth noting.
The first is the support for custom literals . We did not take up this task for a long time, but the growing popularity of the concept of the built-in type and the appearance of its use in std :: chrono and other parts of the standard library led us to the need for its support. It is worth noting that in addition to reducing the number of false-positive errors of the code analyzer (which were caused by the lack of support for user literals) and the Quick Documentation pop-up window (
Ctrl+Qon Lin / Win,F1on macOS), which now correctly reflects the type, CLion also allows you to rename literals, updating the definition and all its uses: Since we are talking about operators, it is worth noting that CLion can now look for cases of using overloaded operators (except for new and delete), which can be especially useful when meeting new and unknown code that actively uses this feature of the language:
Another reason for multiple errors of the built-in code analyzer that was fixed in this release is fixes in support of overload resolution. Now CLion can choose the right candidate correctly, which means that it will correctly show the unused code, find all uses, rename the function or change its signature, etc. And along with this, the development environment will now point you to an ambiguous call or the lack of a suitable function to call - the appropriate inspections were added in CLion 2016.3:
In general, our team has expanded, and in particular, we have more people involved in code analysis. Thanks to this release 2016.3 brought many changes in this area. For example, analysis that relies on sizeof () calculations has become platform dependent. We also corrected an erroneous warning about an unused variable in the case of a nontrivial destructor (which is especially important for the so-called ' guard ' idiom):
In addition, CLion now understands and correctly considers __attribute __ (unused) and __builtin_unreachable when analyzing the code. And these are just a few of the many static code analysis enhancements that came in CLion 2016.3.
An important step in the further development of language support can be considered the emergence of support for the separator characters (C ++ 14). We hope that in the future we will be able to devote time to other possibilities of the latest C ++ language standards. If you want to draw our attention to something specific, we recommend that you vote for the appropriate tasks in our tracker .
Support C: C11
Our users quite reasonably noticed that support for pure C in CLion is a little lame. We finally decided to fix this and added support for gcc atomic builtins and the _Generic keyword , and for the keywords _Thread_local , _Alignas , _Noreturn , _Static_assert , and _Atomic , which appeared in updates to version 2016.2, this version added auto-completion to speed up the writing process code:
Someone here may recall that in this version it was planned to add project templates, in particular for the C project. We are forced to honestly admit that the work is ongoing, but not yet completed. But already in one of the upcoming updates 2016.3.x templates will appear.
CMake: A New Approach
These changes were preceded by a lot of controversy and discussion. Unfortunately, our initial approach did not suit many. Objective criticism was actively accumulating in the tracker. For example, a request to change the directory in which CMake is generated collected ~ 90 votes and ~ 90 comments. On a blog, on Twitter, live at a variety of conferences and exhibitions, we have repeatedly discussed performance problems caused by the fact that CLion collected all four CMake configurations for each project (Debug, Release, RelWithDebInfo, MinSizeRel). And finally, in version 2016.3, we substantially reworked the approach and proposed a solution to the accumulated problems.
Now CLion collects only the selected configuration . This setting, as well as the path to the directory where you want to generate, is in the dialog of design settings Build, Execution, Deployment | CMake By default, the project is built in a directory inside the project source code named cmake-build-debug . In the future, we plan to enable users to change the default values (for example, to specify the directory for the assembly common to all your projects).
Thanks to these changes, it was also possible to open the project from the directory where CMake was already generated without calling CMake again, which significantly saves time opening the project. To open a project, it is enough to specify the assembly directory or the CMakeCache.txt file:
Please note that this only works if Makefiles were used as a generator. Otherwise, CLion will cause CMake regeneration.
CMake, as you know, the system is not the easiest, especially for beginners. To simplify the debugging of CMake scripts, we added the ability to see the logs of invoking the CMake command in the CMake window. But the CMake Cache editor has been removed. Instead, the development environment opens the CMakeCache.txt file directly in the editor, which makes it easy to add new values. In future releases, we plan to teach CLion the “language” of CMake Cache files to make working with them faster and more convenient.
Remote debugging
In the last release, we added the ability to debug from CLion applications running on a remote machine from under the GDB server. True, not all combinations of local and remote platforms were available. The release of 2016.3 brought the ability to remotely debug from the Windows platform:
- Applications running on another Windows machine and compiled with the same tools from which debugging is performed (MinGW / MinGW-w64 / Cygwin).
- Applications running on another Windows machine and collected by tools different from the one under which debugging is conducted (assembled MinGW - debugged in Cygwin, etc.). In this case, it is necessary to specify in the configuration in CLion the correct correspondence of the paths of the local and remote machines.
- Applications running on a Linux machine. Here you will need a cross-platform GDB debugger (that is, the standard one in CLion will not work). You can read about how to assemble it in our blog . Of course, you will need a properly configured configuration, indicating the path to the file with debugging symbols and the correspondence of the paths of the local and remote machines.
By the way, in addition to remote debugging, a lot of corrections have occurred in the debugger. So, for example, CLion no longer overwrites the PYTHONPATH environment variable , which in particular allows you to debug C extensions for Python (Python C extension modules).
Semantic highlighting and more
Another long-awaited feature is semantic highlighting! I’ll say right away how to turn it on: go to the Editor | Color & Fonts | Language Defaults, find the Semantic highlighting group there and check the Unique color for each parameter and local variable checkbox . Further, you can adjust the color ranges as you wish, or use the default values.
Semantic highlighting is designed to better understand how the data flow changes during the execution of your program. To do this, all variables and parameters are painted (if possible) in different colors.
How it works in CLion:
- Each local variable and parameter is assigned its own color.
- Inside a function or lambda body, CLion tries to avoid repeating colors.
- Identifiers with the same names get the same color.
Well, it looks something like this:
Another change related to code highlighting is the automatic switching of the resolve context in the editor when changing the configuration. Let's see why this might be necessary.
Imagine a situation where a source file is included in the assembly of two different CMake targets. At the same time, the settings for these targets are different, and in the code itself there are conditional compilation blocks depending on these settings. What about the code editor in this situation? How to correctly highlight these parts of the code, how to look for cases of use, how to produce the correct code refactoring? The answer is simple: select the settings of a single target and use them. But which one? It seems logical to us that the one you are working on now and which you are collecting / debugging at a given time. Therefore, when switching the Run / Debug configuration, CLion 2016.3 automatically switches the resolve context for the file:
If nevertheless this is not what you want, use the manual switching of the resolve context in the lower right corner of the editor. Automatic switching in this case will be disabled until the next restart of the IDE (but this is more a bug than a feature).
Unreal engine
Here on Habré there were already several discussions of game development using Unreal Engine in CLion. As part of this release, we decided to see how we can help users in this case. And the reason was the emergence of a third-party plug-in for Unreal Engine, which allows you to open a project in CLion, generating the necessary CMake scripts for it. We tried this plugin and were pleasantly surprised by the fact that the resulting CMake allows CLion to index the project faster, since it does not include all the source codes of the game engine, but only the necessary part.
Having rejoiced, we significantly reduced the time for re-opening the already indexed project in CLion. Our colleague also added a plugin.for autocompletion of reflection specifiers:
A detailed post on how to develop games based on Unreal Engine in CLion can be read on our blog .
Other changes
There are many other changes and corrections in the release of CLion 2016.3, but in order not to delay, we will mention them only briefly:
- Generating a documentation template in the Doxygen format is now able to work with C ++ templates, generating the tparam tag for template parameters of functions, structures and classes :
- The Find in Path dialog now saves search settings (such as the selected scope, filter by file name, etc.), regardless of which path this action is called.
- Together with the entire IntelliJ platform, the CLion 2016.3 release includes improvements in support of version control systems, such as sign-off commits, the ability to roll back an action that has not yet been called push, the ability to restore a deleted local branch, improved search performance on Git / Mercurial logs and another.
- And for macOS Sierra users, the release includes a critical fix for scrolling in the editor, as well as the San Francisco font (SF NS Text), which is now used by default in both the dark (Darcula) and light (Default) theme.
Below is a short demo in English from Phil Nash, our development lawyer:
In general, if you are interested and want to try the new version, as usual, there is a 30-day free trial , and in the price section you can find out about the cost of the subscription.
Stay tuned for articles and updates on our English-language blog . We will be happy to answer any of your questions in the comments.
Your JetBrains CLion
The Drive to Develop Team