CLion 2017.1 release: C ++ 14, C ++ 17, disassembler code in debugger, Catch, MSVC and much more
Hi, Habr! We're glad to share the good news - we released the first release of our cross-platform IDE for C and C ++ this year, CLion 2017.1 !
Our plans, as usual, slightly exceed our capabilities and resources. But in this release we managed to catch almost all of the planned . In short:
')
And that is not all! Read the details below.
By the way, you can try all the new features on a small demo project that we have specially prepared for this purpose.
Very soon, the C ++ 17 standard will be officially adopted and the C ++ community will begin to actively discuss and make plans for C ++ 19/20. Therefore, in version 2017.1, we tried to fully support all current (and officially adopted) standards of modern C ++.
First we ended up with constexpr from C ++ 11, and then we started C ++ 14, namely, we supported the following features:
The support in this case lies in the correct parsing and rezolve of the corresponding language constructs (as you remember, the CLion parser has its own) and, as a result, in the correct code highlighting, navigation, refactorings, autocompletion and correct operation of the code analyzer.
A typical example is the use of generalized lambda captures , which previously led to the fact that all the lambda code was incorrectly highlighted as unused. Now, as you can see, all is well:
Another example is the use of auto for the return type. In previous versions, CLion could not correctly infer the type of the
Thus, of the uncovered features of the C ++ 14 standard, only constexpr remained. And work has already begun in the direction of C ++ 17: nested namespaces are supported. A complete list of the capabilities of modern C ++ standards supported in CLion can be found here .
With the advent of modern standards in C ++, there have been many significant changes. The code in modern C ++ is significantly different from the code in C ++ of the sample of the 98th or even 2003. And the more actively the language develops, the more urgent is the question of converting the code of the “old” into the “new”. And what if not the IDE can help cope with this task? Refactoring and other code transformations are exactly what we love at JetBrains.
Work in this direction has just begun, and we have a lot of ideas. For now, we have added the ability to convert the type of a variable to auto :
Reverse replacement can also be implemented and even in the plans ( CPP-8555 ).
Precompiled headers (PCH) is a common way to save on compile time if a project uses large header files or just some set of such files is used very often. Moreover, these files rarely change. In such a situation, it makes sense to compile them once and in the future to ask the compiler to reuse the available information.
In such a situation, the IDE has to figure out which PCHs are transferred during compilation, find them, and read the characters from these header files that may be needed for the main project code.
Now CLion can do that. This applies to both PCH and header files passed through the compile -include option. That is, the corresponding classes, functions, etc. from such header files are correctly understood:
Please note that for GCC there are some minor limitations related to the technical features of the implementation.
One of the most popular requests in our tracker is the ability to display assembly code when debugging. In version 2017.1, we implemented two important features associated with this query:
It works disassembly view so far only for GDB. According to the disassembler code, you can walk around to better understand what the program is doing and, possibly, find the problem for which the debugger was launched. Put a breakpoint in this code is not yet possible.
For the future, the possibility of displaying the code on the disassembler is planned, even if the source code of the program is available ( CPP-9091 ).
For C ++ there are a huge number of test frameworks: Google Test, CppUnit, CppTest, Boost, QtTest and others. CLion has been supporting Google Test for quite some time. And in version 2017.1, Catch support appeared. Why Catch?
The main support is a special window with test results (test runner). If a special Run / Debug configuration is used for the launch - Catch - then the output of the results will be carried out there:
In addition to a convenient presentation of the results, in this window you can:
By the way, auto-completion for the tags used in the tests works in the configurations. This helps to quickly set up a set of tests that need to be run as part of the configuration.
You can read more about the features and benefits of Catch and its integration into CLion in our English-language blog .
Probably one of the most interesting features of this version. At least for users on Windows. The fact is that before CLion worked only with GCC / Clang and on Windows it was necessary to install MinGW, MinGW-w64 or Cygwin. And they, in turn, are not always easily and clearly configured during installation, and they have a number of inconveniences in general. So users on Windows quite reasonably asked us to support the Microsoft Visual C ++ compiler. What we did in 2017.1, the truth is still in experimental mode .
To try, you need to enable the corresponding option in the Registry:
Now in the settings of toolchains you will have the opportunity to choose the Microsoft Visual C ++ compiler:
Supported versions of Visual Studio - 2013, 2015, 2017 - are located and determined automatically.
It is worth mentioning that MSVC is still running via CMake (as a generator, which uses NMake along with the usual Makefiles). That is, msbuild is not supported. CLion provides architecture, platform, and version settings in Build, Execution, Deployment | CMake:
Among the important limitations, it is worth noting: the lack of a debugger and the lack of support for specific language extensions from Microsoft. Otherwise, we would be happy if those who were interested in supporting the Microsoft Visual C ++ compiler try it and share their feedback with us.
You can talk about zero-latency typing for quite a while. But we will better offer our readers to get acquainted with a detailed study of this issue from our colleague.
In version 2017.1, by default, the corresponding mode was turned on, which before that (within six months) was in test mode. The solution itself allows to reduce the number of editor redraws, thereby reducing the delay between directly printing the code and drawing it on the screen.
The CLion 2017.1 version includes useful updates for plugins such as Swift, Go, Settings Repository and more.
If we talk about Swift , then the changes should pay attention to those who use or plan to use CLion as Swift IDE on Linux. Thanks to the AppCode command, new features have appeared in the plugin:
Changes to the Go plugin were aimed at bringing it in line with Gogland , a stand-alone IDE based on the IntelliJ platform for this language.
And the plug-in for storing IDE settings in the repository was finally “banned” into the IDE itself.
In version 2017.1, there have been many other changes. So, for example, Find in Path (text search by project or any selected scopes) is available as a popup window with a convenient preview of the result:
And in the log window from the version control system (for Git and Mercurial), it became possible to use regular expressions and choose whether to ignore case or vice versa.
Here is a small demonstration of the new features of CLion 2017.1:
If you are interested, download the 30-day free trial , and in the price section you can learn 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
Our plans, as usual, slightly exceed our capabilities and resources. But in this release we managed to catch almost all of the planned . In short:
')
- C ++ 14 support (all except constexpr )
- Initial C ++ 17 support (we started with the most requested feature — nested namespaces )
- Ability to convert variable type to auto
- During the debugging of the program, in the absence of files with the source code, you can go to the code on the disassembler (disassembly view)
- Catch unit testing framework support
- Significant acceleration of editor response when printing a code (Zero Latency Typing)
- And finally, experimental support for the Microsoft Visual C ++ compiler!
And that is not all! Read the details below.
By the way, you can try all the new features on a small demo project that we have specially prepared for this purpose.
C ++ 14 and C ++ 17
Very soon, the C ++ 17 standard will be officially adopted and the C ++ community will begin to actively discuss and make plans for C ++ 19/20. Therefore, in version 2017.1, we tried to fully support all current (and officially adopted) standards of modern C ++.
First we ended up with constexpr from C ++ 11, and then we started C ++ 14, namely, we supported the following features:
- auto return type ,
- generic lambdas ,
- variable templates , and
- generalized lambda captures .
The support in this case lies in the correct parsing and rezolve of the corresponding language constructs (as you remember, the CLion parser has its own) and, as a result, in the correct code highlighting, navigation, refactorings, autocompletion and correct operation of the code analyzer.
A typical example is the use of generalized lambda captures , which previously led to the fact that all the lambda code was incorrectly highlighted as unused. Now, as you can see, all is well:
Another example is the use of auto for the return type. In previous versions, CLion could not correctly infer the type of the
vec variable, and therefore suggest the correct autocompletion:Thus, of the uncovered features of the C ++ 14 standard, only constexpr remained. And work has already begun in the direction of C ++ 17: nested namespaces are supported. A complete list of the capabilities of modern C ++ standards supported in CLion can be found here .
Make auto
With the advent of modern standards in C ++, there have been many significant changes. The code in modern C ++ is significantly different from the code in C ++ of the sample of the 98th or even 2003. And the more actively the language develops, the more urgent is the question of converting the code of the “old” into the “new”. And what if not the IDE can help cope with this task? Refactoring and other code transformations are exactly what we love at JetBrains.
Work in this direction has just begun, and we have a lot of ideas. For now, we have added the ability to convert the type of a variable to auto :
Reverse replacement can also be implemented and even in the plans ( CPP-8555 ).
PCH
Precompiled headers (PCH) is a common way to save on compile time if a project uses large header files or just some set of such files is used very often. Moreover, these files rarely change. In such a situation, it makes sense to compile them once and in the future to ask the compiler to reuse the available information.
In such a situation, the IDE has to figure out which PCHs are transferred during compilation, find them, and read the characters from these header files that may be needed for the main project code.
Now CLion can do that. This applies to both PCH and header files passed through the compile -include option. That is, the corresponding classes, functions, etc. from such header files are correctly understood:
Please note that for GCC there are some minor limitations related to the technical features of the implementation.
Debugger Disassembly
One of the most popular requests in our tracker is the ability to display assembly code when debugging. In version 2017.1, we implemented two important features associated with this query:
- Syntax highlighting of assembly code in the editor (works only for the AT & T dialect) for files with the .s and .asm extensions, or any other files configured in Settings | Editor | File Types | Assembly Language.
- Display of the code on the disassembler (disassembly view) during debugging during the transition to a call for which there are no source codes of the program.
It works disassembly view so far only for GDB. According to the disassembler code, you can walk around to better understand what the program is doing and, possibly, find the problem for which the debugger was launched. Put a breakpoint in this code is not yet possible.
For the future, the possibility of displaying the code on the disassembler is planned, even if the source code of the program is available ( CPP-9091 ).
Catch
For C ++ there are a huge number of test frameworks: Google Test, CppUnit, CppTest, Boost, QtTest and others. CLion has been supporting Google Test for quite some time. And in version 2017.1, Catch support appeared. Why Catch?
- Catch is very easy to start using. To connect Catch to your project, just download and add a single header file to the project. Convenient, isn't it?
- Test cases in Catch are quite flexible and convenient.
- Since the fall of last year, the author of the Catch framework, Phil Nash , has been working with us at JetBrains as a C ++ developer attorney with the company's products. So, in parallel with the Catch support in CLion, the framework itself was also being finalized. Which, of course, greatly helped the development.
The main support is a special window with test results (test runner). If a special Run / Debug configuration is used for the launch - Catch - then the output of the results will be carried out there:
In addition to a convenient presentation of the results, in this window you can:
- restart all tests or just dropped;
- sort tests by name or by duration;
- view / go to the specific test code;
- view the output of each specific test and error messages;
- transfer the results of the current test run to a file;
- view previous runs of tests on the history, which is saved automatically.
By the way, auto-completion for the tags used in the tests works in the configurations. This helps to quickly set up a set of tests that need to be run as part of the configuration.
You can read more about the features and benefits of Catch and its integration into CLion in our English-language blog .
Microsoft Visual C ++ Compiler
Probably one of the most interesting features of this version. At least for users on Windows. The fact is that before CLion worked only with GCC / Clang and on Windows it was necessary to install MinGW, MinGW-w64 or Cygwin. And they, in turn, are not always easily and clearly configured during installation, and they have a number of inconveniences in general. So users on Windows quite reasonably asked us to support the Microsoft Visual C ++ compiler. What we did in 2017.1, the truth is still in experimental mode .
To try, you need to enable the corresponding option in the Registry:
- Open the Find Action dialog (
Shift+Ctrl+Aon Linux / Windows,⇧⌘Aon macOS) - Enter the registry
- Select and open Registry editor.
- Start typing clion.enable.msvc - CLion will find a suitable option in the list.
- Turn on and use MSVC!
Now in the settings of toolchains you will have the opportunity to choose the Microsoft Visual C ++ compiler:
Supported versions of Visual Studio - 2013, 2015, 2017 - are located and determined automatically.
It is worth mentioning that MSVC is still running via CMake (as a generator, which uses NMake along with the usual Makefiles). That is, msbuild is not supported. CLion provides architecture, platform, and version settings in Build, Execution, Deployment | CMake:
Among the important limitations, it is worth noting: the lack of a debugger and the lack of support for specific language extensions from Microsoft. Otherwise, we would be happy if those who were interested in supporting the Microsoft Visual C ++ compiler try it and share their feedback with us.
Zero latency typing
You can talk about zero-latency typing for quite a while. But we will better offer our readers to get acquainted with a detailed study of this issue from our colleague.
In version 2017.1, by default, the corresponding mode was turned on, which before that (within six months) was in test mode. The solution itself allows to reduce the number of editor redraws, thereby reducing the delay between directly printing the code and drawing it on the screen.
Plugins
The CLion 2017.1 version includes useful updates for plugins such as Swift, Go, Settings Repository and more.
If we talk about Swift , then the changes should pay attention to those who use or plan to use CLion as Swift IDE on Linux. Thanks to the AppCode command, new features have appeared in the plugin:
- template for creating a new Swift project, with a pre-filled CMake file and Package.swift;
- errors, warnings and possible fixes from SourceKit-based code analyzer;
- the ability to generate a type of variable after its use.
Changes to the Go plugin were aimed at bringing it in line with Gogland , a stand-alone IDE based on the IntelliJ platform for this language.
And the plug-in for storing IDE settings in the repository was finally “banned” into the IDE itself.
And much more
In version 2017.1, there have been many other changes. So, for example, Find in Path (text search by project or any selected scopes) is available as a popup window with a convenient preview of the result:
And in the log window from the version control system (for Git and Mercurial), it became possible to use regular expressions and choose whether to ignore case or vice versa.
Here is a small demonstration of the new features of CLion 2017.1:
If you are interested, download the 30-day free trial , and in the price section you can learn 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/325372/
All Articles