CLion 2019.1: ClangFormat, code highlighting via Clangd, memory view, initial microcontroller support
Hi, Habr!
The CLion team has a lot of great news - the St. Petersburg part of the team, together with other colleagues, successfully moved to a new office, new cool developers joined us, and most importantly, we just recently released the first big update this year, CLion 2019.1 !
Work in the new version went on several fronts at once:
')
Read more about these and other innovations below. And to try new features and improvements, download the free 30-day version of CLion from our website .
As you already know, in CLion there are two tools for supporting the C ++ language - one completely different and the other based on Clangd. They work together, complementing each other and sharing the necessary information. At the same time, if the performance and the criterion of functional completeness allow, we are now trying to transfer smart tools for working with C ++ code in CLion to a tool based on Clangd. This is not about refactoring code, but the code highlighting in 2019.1 has already been made on the basis of Clangd. This greatly improved the editor's responsiveness.
A few more releases back we switched CLion to a Clangd-based tool while showing errors in the editor. Now the error text is shown in more detail. This is useful, for example, when debugging errors associated with overloading functions:
Added to this is the ability to calculate the position of a possible fix (quick-fix) also via Clangd. The fix itself is provided directly by the CLion own tool.
Another interesting area of our work is writing new checks on the Clangd code parsing tool. Starting from CLion 2019.1, a new check for C ++ code will tell you when a member function of a class can be declared static:
By the way, the settings management of this alternative tool on Clangd can be found in Settings / Preferences | Languages & Frameworks | C / C ++ | Clangd.
Performance editor is one of our top priorities. In addition to many small improvements in this release, it is worth noting a significant improvement in the initial indexing time of the project. It does not always happen, but in cases where you use the same libraries for your projects: then CLion can automatically notice and reuse the symbols for these libraries for a new open project that uses them. When it comes to STL or Boost, improvements are very noticeable!
Our plans for this year are to increase the accuracy and accuracy of our refactorings for C ++. We started with the two most basic ones - Rename and Extract. For Extract, we fixed a lot of cases when the result of refactoring turned out to be incorrect due to incorrectly taken namespace qualifiers (for example,
With regard to Rename, we paid attention to the case when a class or structure is renamed, which coincides with the name of the file in which they are located. Previously, we always renamed the file too, and now CLion asks you about the preferred outcome during refactoring. You can rename, or you can leave the old file name. The opposite direction also works - renaming a file does not lead to unconditional renaming of a class. (Somewhere here there should be shouts from the audience: “Finally!”.)
And, by the way, just below I will talk about the possibility of setting styles for header guards. So, if the header guard used in the file follows the specified style pattern and there is a name of the renamed file in its name, then CLion will update header guard!
In version 2019.1, we added the ability to switch to ClangFormat to format the code in CLion. This includes not only the formatting action itself (
You can switch to ClangFormat globally - in Settings / Preferences | Editor | Code Style. And you can only for a specific project. Moreover, if a .clang-format configuration file is found in the project, CLion will offer to switch to ClangFormat using this configuration file:
Slightly more details can be found in our blog (in English).
Naming variables, types, and other symbols in code is a complex, sometimes even a philosophical question. But in the programming world (to improve code readability), naming styles have long been invented. There is an LLVM style, there is Qt, there is Google. Therefore, in the settings CLion Settings / Preferences | Editor | Code Style | C / C ++ now has a new tab, Naming Convention, in which you can choose one of the predefined styles or customize your own by setting the naming style for various types of characters (macros, global functions, class members, parameters, local variables, etc.). The selected convention will be used in all IDE code generation, refactoring, automatic fixes, etc. In addition, if you want to follow naming rules even more accurately, you can enable new Inconsistent Naming check, which will show names that do not comply with the rules, and will offer the option of renaming:
In the same tab, you can find the header guards style settings that I mentioned above:
By the way, if you prefer to use
We finally got around to viewing the memory in the debugger. In the current version, you can see the memory by pointer: just get up on any point in the Variables panel during debugging and request a Memory View (
The next release is already scheduled for changes in UI / UX, but first I would like to collect feedback from users. So write!
The assembler code is now broken down by function and, most importantly, shown not only in the case of GDB, but also for LLDB!
It is worth noting, however, that the assembler code is shown so far only in cases where there are no source codes of the function. The so-called disassemble on demand mode is not yet supported.
Sometimes, step-by-step debugging is delayed due to the lengthy computation of variables at each step. But sometimes these calculations are not needed by anyone - I want to go through a certain area of the code step by step as quickly as possible, occasionally looking at the values of a couple of variables! Now CLion has an opportunity to turn off variable recalculation during step-by-step debugging - the Mute Variables in the context menu of the debugger does exactly that. And when you need to calculate and display the values, you can click Load on the variable:
Ilya Motorny ( elmot ) already wrote here on Habré about his plugin for integrating CLion with STM32CubeMX and OpenOCD debugger support. At the end of last year, Ilya joined our team and already managed to significantly update the plugin and move it inside of CLion.
A rather large and detailed blog post on the updated plugin can be found in our blog . Here I will describe the most important thing that can now be done:
Ilya has many ambitious plans, so your feedback is very important to us. So, if you are interested in the development of embedded systems in CLion, we are waiting for you in the comments!
Some time ago the Gradle C ++ and compilation database were expanded to a list of supported project models in CLion. There were problems with the latter due to the fact that the format does not include information about the assembly of the entire project, therefore neither the assembly, nor the launch, nor the debugging of the project were possible in the case of compilation database. And just in the case of the well-known CLion design model, sometimes you want to have a target, which is simply assembled by some team in the terminal.
Now for such cases there are Custom Targets (Settings / Preferences | Build, Execution, Deployment | Custom Build Targets) and Custom Run / Debug Configurations (Run | Edit Configurations ...). In the case of a target, it is necessary to set the parameters of external tools (external tools) that will be used when assembling and cleaning the project:
And in the case of a project-independent configuration, for launching and debugging, you must specify the target, the executable file and the desired arguments for launching:
Are there string literals in your code that contain a SQL query, HTML code, or regular expression? If yes, then surely you would like to at least highlight the code inside the literal in accordance with its origin. Now it is possible! You can temporarily turn on another language in the string literal simply by pressing
Products at JetBrains are typically created not by one small team, but by the team of the entire relevant platform. Therefore, the opportunities from IntelliJ IDEA, WebStorm, AppCode, DataGrip, PyCharm, etc. are included in CLion. In this release, it is worth noting the following improvements:
That's all for now. Thank you if you have read to the end!
Well, the traditional video about the new features of CLion 2019.1 (in English):
Questions, suggestions, bug reports and just thoughts expressed in the comments! We will be happy to answer.
Your JetBrains CLion Team
The Drive to Develop
The CLion team has a lot of great news - the St. Petersburg part of the team, together with other colleagues, successfully moved to a new office, new cool developers joined us, and most importantly, we just recently released the first big update this year, CLion 2019.1 !
Work in the new version went on several fronts at once:
')
- C ++ language support enhancements : highlighting code through Clangd, extract and Rename refactor improvements, a new test that a member function of a class can be declared static.
- More options in coding style settings : integration with ClangFormat, support for variable naming styles in C / C ++, support for different styles for header guards.
- New features and debugger enhancements : viewing memory status - Memory View - for pointers, viewing disassembled code in the case of LLDB, step-by-step debugging acceleration.
- CLion for microcontrollers , the first steps.
- Ability to create Build Targets and configurations for startup / debugging in CLion that are not related to the design model.
- Work with other programming languages in string literals in C / C ++.
- New visual themes and other platform features.
Read more about these and other innovations below. And to try new features and improvements, download the free 30-day version of CLion from our website .
C ++ language support
Clangd
As you already know, in CLion there are two tools for supporting the C ++ language - one completely different and the other based on Clangd. They work together, complementing each other and sharing the necessary information. At the same time, if the performance and the criterion of functional completeness allow, we are now trying to transfer smart tools for working with C ++ code in CLion to a tool based on Clangd. This is not about refactoring code, but the code highlighting in 2019.1 has already been made on the basis of Clangd. This greatly improved the editor's responsiveness.
A few more releases back we switched CLion to a Clangd-based tool while showing errors in the editor. Now the error text is shown in more detail. This is useful, for example, when debugging errors associated with overloading functions:
Added to this is the ability to calculate the position of a possible fix (quick-fix) also via Clangd. The fix itself is provided directly by the CLion own tool.
Another interesting area of our work is writing new checks on the Clangd code parsing tool. Starting from CLion 2019.1, a new check for C ++ code will tell you when a member function of a class can be declared static:
By the way, the settings management of this alternative tool on Clangd can be found in Settings / Preferences | Languages & Frameworks | C / C ++ | Clangd.
Own code parsing tool
Performance editor is one of our top priorities. In addition to many small improvements in this release, it is worth noting a significant improvement in the initial indexing time of the project. It does not always happen, but in cases where you use the same libraries for your projects: then CLion can automatically notice and reuse the symbols for these libraries for a new open project that uses them. When it comes to STL or Boost, improvements are very noticeable!
Our plans for this year are to increase the accuracy and accuracy of our refactorings for C ++. We started with the two most basic ones - Rename and Extract. For Extract, we fixed a lot of cases when the result of refactoring turned out to be incorrect due to incorrectly taken namespace qualifiers (for example,
std:: , template specializations, and redefined type names (type aliases).With regard to Rename, we paid attention to the case when a class or structure is renamed, which coincides with the name of the file in which they are located. Previously, we always renamed the file too, and now CLion asks you about the preferred outcome during refactoring. You can rename, or you can leave the old file name. The opposite direction also works - renaming a file does not lead to unconditional renaming of a class. (Somewhere here there should be shouts from the audience: “Finally!”.)
And, by the way, just below I will talk about the possibility of setting styles for header guards. So, if the header guard used in the file follows the specified style pattern and there is a name of the renamed file in its name, then CLion will update header guard!
Coding styles
In version 2019.1, we added the ability to switch to ClangFormat to format the code in CLion. This includes not only the formatting action itself (
Ctrl+Alt+L on Windows / Linux, ⌥⌘L on macOS) or auto-formatting when printing the code, but also formatting before the commit (pre-commit hook), when generating the code using CLion, when refactoring and when applying fixes (quick-fixes). In general, at any place where IDE formats the code, ClangFormat will be called.You can switch to ClangFormat globally - in Settings / Preferences | Editor | Code Style. And you can only for a specific project. Moreover, if a .clang-format configuration file is found in the project, CLion will offer to switch to ClangFormat using this configuration file:
Slightly more details can be found in our blog (in English).
Naming variables, types, and other symbols in code is a complex, sometimes even a philosophical question. But in the programming world (to improve code readability), naming styles have long been invented. There is an LLVM style, there is Qt, there is Google. Therefore, in the settings CLion Settings / Preferences | Editor | Code Style | C / C ++ now has a new tab, Naming Convention, in which you can choose one of the predefined styles or customize your own by setting the naming style for various types of characters (macros, global functions, class members, parameters, local variables, etc.). The selected convention will be used in all IDE code generation, refactoring, automatic fixes, etc. In addition, if you want to follow naming rules even more accurately, you can enable new Inconsistent Naming check, which will show names that do not comply with the rules, and will offer the option of renaming:
In the same tab, you can find the header guards style settings that I mentioned above:
By the way, if you prefer to use
#pragma , then just correct the template of new header files in Settings / Preferences | Editor | File and Code Templates.Debugger
View Memory View
We finally got around to viewing the memory in the debugger. In the current version, you can see the memory by pointer: just get up on any point in the Variables panel during debugging and request a Memory View (
Ctrl+Enter on Windows / Linux, ⌘Enter on macOS). And if the memory view tab is open during step-by-step debugging, then in it you can see highlighted changes in memory:The next release is already scheduled for changes in UI / UX, but first I would like to collect feedback from users. So write!
Disassembling in the case of LLDB
The assembler code is now broken down by function and, most importantly, shown not only in the case of GDB, but also for LLDB!
It is worth noting, however, that the assembler code is shown so far only in cases where there are no source codes of the function. The so-called disassemble on demand mode is not yet supported.
Step Debug Performance
Sometimes, step-by-step debugging is delayed due to the lengthy computation of variables at each step. But sometimes these calculations are not needed by anyone - I want to go through a certain area of the code step by step as quickly as possible, occasionally looking at the values of a couple of variables! Now CLion has an opportunity to turn off variable recalculation during step-by-step debugging - the Mute Variables in the context menu of the debugger does exactly that. And when you need to calculate and display the values, you can click Load on the variable:
CLion for microcontrollers
Ilya Motorny ( elmot ) already wrote here on Habré about his plugin for integrating CLion with STM32CubeMX and OpenOCD debugger support. At the end of last year, Ilya joined our team and already managed to significantly update the plugin and move it inside of CLion.
A rather large and detailed blog post on the updated plugin can be found in our blog . Here I will describe the most important thing that can now be done:
- In the New Project dialog, you can create an STM32CubeMX ( .ioc ) project.
- Run directly from CLion for the STM32CubeMX project to update the microcontroller settings and generate code for the project.
- At the same time, CLion itself will generate the correct CMake file for working with this project.
- CLion will suggest selecting a configuration file for hardware (board config).
- To debug using OpenOCD, you need to create a special configuration of the “OpenOCD Download and Run” type. For the project STM32CubeMX CLion will create such a self. By specifying all the settings, you can debug on the microcontroller directly from the CLion!
Ilya has many ambitious plans, so your feedback is very important to us. So, if you are interested in the development of embedded systems in CLion, we are waiting for you in the comments!
Project-Independent Targets and Configurations
Some time ago the Gradle C ++ and compilation database were expanded to a list of supported project models in CLion. There were problems with the latter due to the fact that the format does not include information about the assembly of the entire project, therefore neither the assembly, nor the launch, nor the debugging of the project were possible in the case of compilation database. And just in the case of the well-known CLion design model, sometimes you want to have a target, which is simply assembled by some team in the terminal.
Now for such cases there are Custom Targets (Settings / Preferences | Build, Execution, Deployment | Custom Build Targets) and Custom Run / Debug Configurations (Run | Edit Configurations ...). In the case of a target, it is necessary to set the parameters of external tools (external tools) that will be used when assembling and cleaning the project:
And in the case of a project-independent configuration, for launching and debugging, you must specify the target, the executable file and the desired arguments for launching:
Injected Language
Are there string literals in your code that contain a SQL query, HTML code, or regular expression? If yes, then surely you would like to at least highlight the code inside the literal in accordance with its origin. Now it is possible! You can temporarily turn on another language in the string literal simply by pressing
Alt+Enter and selecting the “Inject language or reference” option. Now we select the language we need and in a more recently ordinary string literal there appears the highlighting of the selected language, as well as all special actions. The most striking example is regular expressions and the ability to check a string for compliance with it directly in the IDE:And much more
Products at JetBrains are typically created not by one small team, but by the team of the entire relevant platform. Therefore, the opportunities from IntelliJ IDEA, WebStorm, AppCode, DataGrip, PyCharm, etc. are included in CLion. In this release, it is worth noting the following improvements:
- View all the places in the project code where the developer made some changes or just read the code - Recent Locations Popup (
Shift+Ctrl+Eon Win / Lin,⇧⌘Eon macOS). - Creating new themes for the IDE interface, in addition to the standard light, dark (Darcula) and contrast (High-Contrast). Examples of such plugin themes and step-by-step tutorial can be found in our documentation .
- Speaking of plugins. If you write on Rust, you probably know that there is a plugin IntelliJ Rust. In CLion, its version includes Cargo support and a debugger. And with the new release, code profiling tools on Linux and macOS have appeared in the plugin, as well as the ability to autocomplete characters that have not yet been imported, as well as other improvements.
That's all for now. Thank you if you have read to the end!
Demo
Well, the traditional video about the new features of CLion 2019.1 (in English):
Questions, suggestions, bug reports and just thoughts expressed in the comments! We will be happy to answer.
Your JetBrains CLion Team
The Drive to Develop
Source: https://habr.com/ru/post/445646/
All Articles