The release of CLion 2016.3: improved support for C11, C ++ 11 and C ++ 14, changes in working with the CMake design model and much more
Hi, Habr! The year is slowly coming to an end, someone is already preparing for celebrations, and someone else is trying to complete all his plans. And here we have released the third release of our cross-platform IDE for C and C ++ development 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 has become much more mature:
We tried to listen to our users (as far as possible) and focus on their requests. Version 2016.3 is no exception and brought many long-awaited improvements:
And now about everything in order.
')
As you probably know (after all, we are asked 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 it is worth noting several significant improvements.
The first is support for custom literals . We didn’t undertake this task for a long time, but the increasing 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 to support it. It is worth noting that in addition to reducing the number of false-positive code analyzer errors (which were caused by the lack of support for custom literals) and the Quick Documentation pop-up window (
If we are talking about operators, it is worth noting that CLion is now able to look for cases of using overloaded operators (except new and delete), which can be especially useful when meeting new and unknown code that actively uses this language feature:
Another reason for the multiple errors of the built-in code analyzer that has been fixed in this release is the fixes in support for overload resolution . Now CLion can select the right candidate correctly, which means correctly display unused code, find all uses, rename a function or change its signature, etc. And at the same time, the development environment will now point you to an ambiguous call or the lack of a suitable function to call - the relevant inspections are 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 relying on sizeof () calculations has become platform dependent. We also corrected an erroneous warning about an unused variable in the case of a non-trivial 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 examples of the many static code analysis enhancements found in CLion 2016.3.
An important step in the further development of language support can be considered the emergence of support for the separator bits (C ++ 14). We hope that in the future we will be able to devote time to other features of the latest C ++ language standards. If you want to draw our attention to something specific, we recommend voting for the corresponding tasks in our tracker .
Our users quite reasonably noticed that the support of pure C in CLion is a bit lame. We finally decided to fix it and added support for gcc atomic builtins and the _Generic keyword , and for the _Thread_local , _Alignas , _Noreturn , _Static_assert , and _Atomic keywords that appeared in the updates to version 2016.2, this version has the option of 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. Forced to honestly admit that the work is underway, but not yet finished. But already in one of the next updates 2016.3.x templates will appear.
These changes were preceded by many disputes and discussions. Our initial approach, unfortunately, did not suit many. Objective criticism is actively accumulated in the tracker. So, for example, a request for changing the directory in which CMake is generated takes about ~ 90 votes and ~ 90 comments. In a blog, on Twitter, live at various conferences and exhibitions, we 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 have 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 project settings dialog Build, Execution, Deployment | CMake. By default, the project is built in a directory within the source code of the project named cmake-build-debug . In the future, we plan to allow users to change default values ​​(for example, to specify the build directory common to all your projects).
Thanks to these changes, it was also possible to open a project from a directory where CMake was already generated, without having to call CMake again, which significantly saves time on opening a project. To open a project, it is enough to specify the build directory or the CMakeCache.txt file:
Please note that this only works for the time being when Makefiles were used as a generator. Otherwise, CLion will cause a CMake regeneration.
CMake, as you know, the system is not the easiest, especially for beginners. To simplify debugging of CMake scripts, we added the ability to see the logs of the CMake command call in the CMake window. But the editor CMake Cache 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 the next 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 applications running on a remote machine from under the GDB server from CLion. True, not all combinations of local and remote platforms were available. Release 2016.3 brought the ability to remotely debug from the Windows platform:
By the way, in addition to remote debugging, a whole host of fixes have occurred in the debugger. 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 opportunity is semantic highlighting! Immediately I will say how to enable: go to Settings Editor | Color & Fonts | Language Defaults, find the Semantic highlighting group there and tick Unique color for each parameter and local variable . Then you can adjust the color ranges at your own discretion or use the default values.
Semantic highlighting is designed to better understand how the data stream changes as your program executes. To do this, all variables and parameters are painted (if possible) in different colors.
How it works in CLion:
Well, it looks like this:
Another change related to the code highlighting is the automatic switching of the resolve context in the editor when the configuration changes. Let's see why this may be necessary.
Imagine the situation that the source file is included in the assembly of two different CMake targets. At the same time, the settings of these targets are different, and in the code itself there are conditional compilation blocks depending on these settings. How to be a code editor in this situation? How to highlight these parts of the code, how to look for use cases, how to produce correct code refactoring? The answer is simple: choose the settings of a single target and use them. But what? It seems to us logical that the one you are working on and that you are collecting / debugging at a given time. Therefore, when switching the Run / Debug configuration, CLion 2016.3 automatically switches and resolve the context for the file:
If, however, 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 likely a bug than a feature).
Here on Habré there have already been several discussions of game development using the 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 appearance of a third-party plug-in for the 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, as it does not include all the source codes of the game engine, but only the necessary part.
Having been delighted, we have significantly reduced the time of re-opening of an already indexed project in CLion. And also our colleague added a plugin for autocompletion of reflection specifiers:
A detailed post on how to develop games based on the Unreal Engine in CLion can be found in our blog .
In the release of CLion 2016.3 there are many other changes and edits, but in order not to delay, we mention them only briefly:
Below is a short demo in English from Phil Nash, our developer lawyer:
In general, if you are interested and you 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 a subscription.
Watch also for articles and updates in our English-language blog . We will be happy to answer any of your questions in the comments.
Your JetBrains CLion Team
The Drive to Develop
- As in terms of language support (variadic templates, auto-import and just numerous fixes in the code analysis part),
- So in terms of a variety of features that increase development productivity (new code generation options, complete statement, refactoring in CMake),
- New languages ​​(Python, Swift),
- And, of course, tools related to development in C and C ++ (remote debugging and debugging of processes running not 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 is no exception and brought many long-awaited improvements:
- In addition to the missing features of C ++ 11, we were finally able to start supporting the capabilities of the C ++ 14 and C11 standards.
- A revised approach to working with the CMake project model solved many difficulties faced by our users (from the inability to change the directory in which CMake generation runs to problems with performance and memory consumption).
- Remote debugging is now possible on the Windows platform.
- A semantic highlight appeared in the editor.
- Improved performance when re-indexing projects based on the Unreal Engine, and we also studied the current state of a third-party plug-in for generating CMake for projects on UE4 and wrote about it a whole separate post .
- Many other improvements and changes.
And now about everything in order.
')
C ++ support: C ++ 11 and C ++ 14
As you probably know (after all, we are asked 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 it is worth noting several significant improvements.
The first is support for custom literals . We didn’t undertake this task for a long time, but the increasing 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 to support it. It is worth noting that in addition to reducing the number of false-positive code analyzer errors (which were caused by the lack of support for custom literals) and the Quick Documentation pop-up window (
Ctrl+Q on Lin / Win, F1 on macOS), which now correctly reflects the type, CLion also allows rename literals by updating the definition and all its uses:If we are talking about operators, it is worth noting that CLion is now able to look for cases of using overloaded operators (except new and delete), which can be especially useful when meeting new and unknown code that actively uses this language feature:
Another reason for the multiple errors of the built-in code analyzer that has been fixed in this release is the fixes in support for overload resolution . Now CLion can select the right candidate correctly, which means correctly display unused code, find all uses, rename a function or change its signature, etc. And at the same time, the development environment will now point you to an ambiguous call or the lack of a suitable function to call - the relevant inspections are 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 relying on sizeof () calculations has become platform dependent. We also corrected an erroneous warning about an unused variable in the case of a non-trivial 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 examples of the many static code analysis enhancements found in CLion 2016.3.
An important step in the further development of language support can be considered the emergence of support for the separator bits (C ++ 14). We hope that in the future we will be able to devote time to other features of the latest C ++ language standards. If you want to draw our attention to something specific, we recommend voting for the corresponding tasks in our tracker .
C: C11 support
Our users quite reasonably noticed that the support of pure C in CLion is a bit lame. We finally decided to fix it and added support for gcc atomic builtins and the _Generic keyword , and for the _Thread_local , _Alignas , _Noreturn , _Static_assert , and _Atomic keywords that appeared in the updates to version 2016.2, this version has the option of 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. Forced to honestly admit that the work is underway, but not yet finished. But already in one of the next updates 2016.3.x templates will appear.
CMake: a new approach
These changes were preceded by many disputes and discussions. Our initial approach, unfortunately, did not suit many. Objective criticism is actively accumulated in the tracker. So, for example, a request for changing the directory in which CMake is generated takes about ~ 90 votes and ~ 90 comments. In a blog, on Twitter, live at various conferences and exhibitions, we 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 have 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 project settings dialog Build, Execution, Deployment | CMake. By default, the project is built in a directory within the source code of the project named cmake-build-debug . In the future, we plan to allow users to change default values ​​(for example, to specify the build directory common to all your projects).
Thanks to these changes, it was also possible to open a project from a directory where CMake was already generated, without having to call CMake again, which significantly saves time on opening a project. To open a project, it is enough to specify the build directory or the CMakeCache.txt file:
Please note that this only works for the time being when Makefiles were used as a generator. Otherwise, CLion will cause a CMake regeneration.
CMake, as you know, the system is not the easiest, especially for beginners. To simplify debugging of CMake scripts, we added the ability to see the logs of the CMake command call in the CMake window. But the editor CMake Cache 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 the next 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 applications running on a remote machine from under the GDB server from CLion. True, not all combinations of local and remote platforms were available. Release 2016.3 brought the ability to remotely debug from the Windows platform:
- Applications running on a different Windows machine and compiled by the same toolkit from which you are debugging (MinGW / MinGW-w64 / Cygwin).
- Applications running on a different Windows machine and assembled by tools other than the one from which you are debugging (compiled MinGW - debugged in Cygwin, etc.). In this case, you need to specify in the configuration in CLion that the paths of the local and remote machines are correctly matched.
- Applications running on a Linux machine. Here you will need a cross-platform GDB debugger (that is, the standard CLion won't work). How to collect it, you can read in our blog . Of course, you will need a properly configured configuration, indicating the path to the file with debugging symbols and the corresponding paths of the local and remote machines.
By the way, in addition to remote debugging, a whole host of fixes have occurred in the debugger. 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 illumination and not only
Another long-awaited opportunity is semantic highlighting! Immediately I will say how to enable: go to Settings Editor | Color & Fonts | Language Defaults, find the Semantic highlighting group there and tick Unique color for each parameter and local variable . Then you can adjust the color ranges at your own discretion or use the default values.
Semantic highlighting is designed to better understand how the data stream changes as your program executes. 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 the function body or lambda, CLion tries to avoid color repetitions.
- Identifiers with the same name get the same color.
Well, it looks like this:
Another change related to the code highlighting is the automatic switching of the resolve context in the editor when the configuration changes. Let's see why this may be necessary.
Imagine the situation that the source file is included in the assembly of two different CMake targets. At the same time, the settings of these targets are different, and in the code itself there are conditional compilation blocks depending on these settings. How to be a code editor in this situation? How to highlight these parts of the code, how to look for use cases, how to produce correct code refactoring? The answer is simple: choose the settings of a single target and use them. But what? It seems to us logical that the one you are working on and that you are collecting / debugging at a given time. Therefore, when switching the Run / Debug configuration, CLion 2016.3 automatically switches and resolve the context for the file:
If, however, 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 likely a bug than a feature).
Unreal engine
Here on Habré there have already been several discussions of game development using the 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 appearance of a third-party plug-in for the 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, as it does not include all the source codes of the game engine, but only the necessary part.
Having been delighted, we have significantly reduced the time of re-opening of an already indexed project in CLion. And also our colleague added a plugin for autocompletion of reflection specifiers:
A detailed post on how to develop games based on the Unreal Engine in CLion can be found in our blog .
Other changes
In the release of CLion 2016.3 there are many other changes and edits, but in order not to delay, we mention them only briefly:
- The generation of the Doxygen documentation template now can work with C ++ templates, generating the tparam tag for the template parameters of functions, structures and classes:
- The Find in Path dialog now saves search settings (such as the selected scop, filter by file name, etc.), regardless of which path this action is called.
- Together with the entire IntelliJ platform, the release of CLion 2016.3 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 a push, the ability to restore a remote local branch, improved search performance over Git / Mercurial logs and another.
- And for users of macOS Sierra, the release included a critical correction of 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) themes.
Below is a short demo in English from Phil Nash, our developer lawyer:
In general, if you are interested and you 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 a subscription.
Watch also for articles and updates in our English-language blog . We will be happy to answer any of your questions in the comments.
Your JetBrains CLion Team
The Drive to Develop
Source: https://habr.com/ru/post/315962/
All Articles