Hi,

A new CLion 2019.3 EAP (build 193.5096.27) is now available! Get it from our website, via the Toolbox App, or as a snap package (if you are using Ubuntu). A patch-update for anyone using the previous EAP build will be available shortly.

DOWNLOAD CLION 2019.3 EAP

Key highlights:

• Support for C++20’s Concepts
• Action to switch between header/source files
• Reading .lldbinit from the project root

Support for C++20’s Concepts in CLion

Concepts are one of the biggest and most important features coming in the C++20 standard. We’ve been collaborating with Saar Raz, the author of the Concepts support in Clang, and have merged his Clang branch into our custom Clangd-based language engine in CLion, and implemented a few things on top:

• Parsing and custom highlighting
• Code inspections, like Unused Concept
• Code completion
  • Completions on template type parameters that are constrained
  • Completion for types constrained by std::is_base_of<MyBase, T> and std::is_same<Other, T>
• Refactorings and navigation actions for Concepts
  • Rename
  • Go to Definition
  • Find Usages

To learn more about CLion’s support for C++20’s Concepts, please see our dedicated blog post.

Action to switch between header/source files

To switch between header/source files, CLion has offered Go to Related Symbol. This IntelliJ platform action is smart as it tries to find related symbols across the whole project, but it may also cause some issues and inaccuracies when used for switching between header/source use case:

• It tries to locate the cursor in the newly opened file on a related class/function definition, which is often inconvenient.
• It tries to find the best option and just goes there without asking the user to select from the available options (this often causes issues for cases with one header plus many source files, or a .h/.inl/.cpp triple).
• Because it tries to be so smart, it might be heavy in terms of performance (as it looks through all the project symbols).
• Several heuristics exist which could be quicker and superior in many situations when switching between header/source. None of them is used by this general Go to Related Symbol action.

To address these issues, we’re introducing a new "Go to Header/Source" action:

As you can see, it either opens a file in the editor right away or shows the popup with various options. This action uses a few heuristics for the search:

1. The most recent switched file is always at the top of the list.
2. Next goes the file with the matching name from the same directory, if any (for example, myfile.h / myfile.cpp).
3. Then, a definition/declaration-based search is performed in the background (which looks for files with definitions with matching declarations in the current file, and vice versa), and new items are added to the popup.
4. Note that the search is currently limited to direct includers/includees so as to avoid interference from the same symbols from different targets.
5. If no single destination is found within 500 ms, CLion shows an interactive popup where new items are added and you can select where you want to navigate to.

There’s one last thing worth mentioning. We understand that CLion users mostly use Go to Related Symbol as a Go to Header/Source action and might be accustomed to this shortcut. From now on, if you invoke Go to Related Symbol via the keyboard shortcut in a C/C++ file, and the non-default shortcut is not yet set for Go to Header/Source, CLion will ask you – only once per installation – if you’d like to remap the current shortcut from Go to Related Symbol to Go to Header/Source:

LLDB: read .lldbinit from the project root

We’ve recently added an ability to read .gdbinit from the project root. It’s now time to enable it for .lldbinit as well.

You may find this useful to tune the LLDB debugger behavior via passing some commands and options in a .lldbinit file. Note that to enable this behavior, you have to explicitly allow it in your home .lldbinit file. Please see this for the exact commands.

Full release notes are here.

DOWNLOAD CLION 2019.3 EAP

Your CLion Team
JetBrains
The Drive to Develop

Concepts are one of the biggest features coming in C++20, and knowing that, we’ve been thinking about supporting Concepts in CLion for quite a while. Enter Saar Raz with his C++20’s Concepts implementation in Clang! Long story short, we have been collaborating with Saar to merge his branch into our custom Clangd-based language engine in CLion, and started implementing some nice IDE features on top. Sounds ambitious enough, but we have thoroughly enjoyed the experience so far! A very early result of this collaboration was used by Saar in his CppCon 2019 talk on Concepts:

We do recommend watching this talk in full to learn how Concepts can be useful, and whether you should care about them even if you’re not using metaprogramming in your daily work.

Now, we are ready to present the C++20’s Concepts support in CLion, available to all the 2019.3 Early Access Program users! Just grab a build and give it a try.

DOWNLOAD CLION 2019.3 EAP

How to get C++20’s Concepts working in your project

All three major compilers are now using the corresponding support:

• Clang
  • As we said earlier, Saar Raz is working on the implementation now. You can build the compiler from his GitHub fork and use it. It’s also available in the Compiler Explorer if you want to experiment with the compiler. Note that the Clang version is not upstreamed yet, so you’ll have to use the branch (Saar is doing his best to upstream the changes as soon as possible).
  • To use it, set the C++ standard to C++20 and pass the options -Xclang -fconcepts-ts to the compiler. In CMake, it will look as follows:
    set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Xclang -fconcepts-ts")
• GCC 10
  • For several releases, GCC supported only the Concepts-TS (under the -fconcepts flag) which is not fully consistent with C++20’s Concepts. However, in the upcoming GCC 10, the Concepts implementation was updated to conform to C++20.
  • With GCC 10, all you need to do is set the C++ standard to C++20.
• Microsoft Visual C++ Compiler
  • MSVC has had Concepts support since Visual Studio 16.3.
  • Just set the C++ standard to C++20.
  • You may also need to add #define __cpp_lib_concepts to get the correct resolve (see the comments to the Microsoft announcement).

In CLion, you should have Clangd-based engine turned on, including code completion from Clangd (which is on by default in Settings/Preferences | Languages & Frameworks | C/C++ | Clangd).

How exactly CLion supports C++20’s Concepts

Here comes the most intriguing part – what is actually supported in CLion? There are four major areas:

• Parsing and highlighting
• Code inspections
• Code completion
• Refactoring and navigation

First of all, CLion can now parse and highlight the Concepts correctly, as we’ve merged the Saar’s Clang Concepts branch into our internal Clangd-based language engine. No more false positives are produced on code with Concepts. All the syntax forms for concept and requires from the standard are supported:

The code highlighting settings for Concepts can be found and customized in Settings/Preferences | Editor | Color Scheme | C/C++ | Concept.

Several code inspections with quick-fixes are available for code using Concepts. Some checks are provided by the compiler, such as:

CLion gives you a dedicated Unused concept inspection.

Speaking of code completion, CLion supports a few cases:

• Completion for template type parameters that are constrained:
  
• Completion for types constrained by
  • std::is_base_of<MyBase, T>
    
  • std::is_same<Other, T> and same_as<T, U>
    

Note that completion on T in std::is_base_of<MyBase, T> and std::is_same<Other, T> will offer available suggestions from MyBase and Other, respectively. But CLion does that only when possible, which means MyBase and Other have to be some concrete types. If template type is used instead, currently no completion is available.

For Concepts in this EAP build, we support the Rename refactoring and navigation actions like Go to Definition and Find Usages.

Known issues

This is still a work in progress on both ends, in CLion and in Saar’s branch, which means you might run into various issues. Hopefully, they only concern Concepts and should not affect you if you are not using C++20’s Concepts in your code.

Some known issues of the current C++20’s Concepts support in CLion:

• Indentation does not always work properly when specifying requirements.
• Because of Clang parser limitations, no completion can be provided for requirements specified in a constexpr if while located in a true-block.
• Completing calls does not insert parentheses.
• These and other CLion issues are linked to the parent ticket CPP-6584 in our tracker.
• You may also be interested in the issues logged in Saar’s GitHub. They might affect the way CLion handles Concepts.

Give Concepts support a try in CLion and let us know what you think!

DOWNLOAD CLION 2019.3 EAP

Your CLion Team
JetBrains
The Drive to Develop

CLion 2019.3 goes Beta! To install CLion 2019.3 Beta (build 193.5233.10), download it from the website, update from our Toolbox App, get it through a snap package (if you are using Ubuntu), or use a patch update.

DOWNLOAD CLION 2019.3 BETA

The main highlights for this build are:

• Completion insert handlers were implemented in Clangd-based language engine, which allows functions/methods to be completed with (), namespaces – with ::, and type aliases – with a space at the end, if they have a built-in underlying type:

• Remote mode:
  • Full Remote Mode in CLion requires rsync (for macOS/Linux clients) or tar (for Windows clients) installed on a remote machine. CLion now verifies the tool is installed and provides a warning on the corresponding remote toolchain settings page, which clearly states that “rsync/tar is not installed or not available in PATH on remote host”.
  • You can now set a custom GDB debugger in the Remote or WSL toolchain (CPP-17552).
  • Resync with Remote Hosts is now enabled on project reload by default. This allows CLion to synchronize the header search paths from the remote machine to the local host (to resolve the code correctly in CLion) on every project reload. This operation might be time-consuming, but as it runs in the background, it shouldn’t affect CLion’s performance. If you are still experiencing any performance issues, try disabling the clion.remote.resync.system.cache registry option (Help -> Find Action, type Registry).
• CMake File API, which makes it possible to use various CMake generators like Ninja in CLion, is now supported not only for v3.15, but for any CMake version higher than 3.15.
• Code coverage now works with a Ninja generator (CPP-17864).
• This build also brings several fixes to code completion and a fix for the lengthy UI freeze (CPP-17961).

The full release notes are available here.

Your CLion Team,
JetBrains
The Drive to Develop

Hi,

Please welcome the Release Candidate for the upcoming CLion 2019.3!

To install CLion 2019.3 RC (build 193.5233.56), download it from the website, update from our Toolbox App, or use a snap package (for Ubuntu). Please note that to use CLion 2019.3 RC, you need to either have an active subscription or start a 30-day evaluation period. No patches are provided for this release candidate, but you can expect a patch from the latest 2019.2.5 update to the 2019.3 release version.

DOWNLOAD CLION 2019.3 RC

Here are the main bug-fixes and improvements:

• C++20’s Concepts completion fixes:
  • Include expressions from required function calls into completion list (CPP-17939).
  • Missing completion for member called as a template function’s argument (CPP-17975).
  • Missing completion for member called inside of static_cast<>() (CPP-17976).
  • Missing completion for a nested type used inside of std::is_copy_constructible (CPP-17978).
• Fixed regressions with Extract parameter (CPP-17970) and Extract Function (CPP-17563).
• Fixed incorrect highlighting of the alias template with Clangd (CPP-15412).

The full release notes are available here. The list of fixes in the JetBrains Runtime can be found here.

Your CLion Team
JetBrains
The Drive to Develop

Exciting news! CLion 2019.3, the last major update this year, has just been released!

Improving the IDE performance and fixing major bugs are always a top priority for our team. In this update we have been focusing especially on improving the performance in specific areas, eliminating UI freezes (not all, but many of them have been melted away!), and enhancing the editor and the integrations for our users!

To update to this version you can use the Toolbox App, snap package (on Ubuntu), our website, or the patch-update from the latest build of 2019.2.

DOWNLOAD CLION 2019.3

If you are just looking for a quick overview of the main highlights, take a look at the list below. If you are interested in the specific details, please read on:

• IDE Performance
• Debugger updates
• More opportunities in CMake
• Switching between Header/Source files
• Code Coverage
• C++20’s Concepts

You can also get a good overview of this release by checking out this short What’s New video by Phil Nash:

IDE Performance

During this release cycle, there were many activities focused on improving the IDE performance, both in the IntelliJ Platform and in CLion in particular.

From the IntelliJ Platform side, a number of significant architectural changes were introduced in order to reduce the IDE startup time. These changes include but are not limited to:

• Parallelization for some of the processes that used to run one after the other.
• Reorganization of the classes in a way that makes the initial class loading faster.
• Optimization of the font loading on macOS.

From the CLion side, we’ve made a massive effort to eliminate UI freezes. While there are still some freezes left (it’s mainly with some of the more complex C++ projects), a lot of others have been melted away. We’re planning to keep up the intensity of this work over the next releases, of this you can be sure! Besides this, we’ve optimized the Building/Updating symbols step by reworking some of the underlying algorithms. Depending on the specific project, CPU, and environment, you can expect a boost of somewhere between 10% and 50%, according to our calculations.

The team has also worked on improving the performance by reworking some of the current core functionality provided by the IDE. First, the Rename refactoring now has a mode where it first asks if you’d like to rename non-code usages (like occurrences in comments and strings literals) and only then performs a search for all the occurences. This, however, requires the in-place mode for Rename to be turned off (Settings/Preferences | Editor | General | Refactorings | Enable in-place mode).

What is probably the most widely used feature of any IDE or smart text editor? That’s right, code completion! To speed up the code completion in CLion, we’ve implemented an additional completion provider. It’s based on Clangd and produces results faster than the other providers in many of the h eavy cases like LLVM, Boost, Qt, or Eigen:

Learn more details on the measurements.

Debugger updates

CLion integrates with GDB and LLDB debuggers, and in this release we have worked on this integration to make it more user-friendly and higher-quality.

For LLDB, we’ve updated the bundled version to v9.0 and performed a major cleanup in the bundled pretty printers. As a result, the standard containers are now visualized more accurately. You can expect much better support for libc++ on macOS than for libstdcxx (let us know if you are using the latter on macOS, and specify the toolchain you use, so that we can consider making improvements). On Ubuntu, the only difference is in the unordered associative containers. Check out a detailed comparison here.

For both GDB and LLDB, CLion now supports reading .gdbinit/.lldbinit from the project root (previously CLion could only read these files from the User’s home directory). This allows you to tune the debugger’s behavior without affecting all the projects on your machine. Note that to enable this behavior, you have to explicitly allow .gdbinit/.lldbinit in your home directory:

• For GDB:
  • Globally:
    set auto-load local-gdbinit on
add-auto-load-safe-path /
  • Per project:
    set auto-load local-gdbinit on
add-auto-load-safe-path C:\work\myproject\.gdbinit
• For LLDB: settings set target.load-cwd-lldbinit true

A typical use case is to provide custom pretty printers for some data types in your project:

And finally, a new Remote GDB Server configuration was added which has made it possible to enable remote debugging over ssh. The main benefit over the previously added GDB Remote Debug configuration, is that CLion uploads the executable to the remote host and launches your program under the gdbserver there automatically. Read the details in our webhelp. This means there are now 3 options to connect remotely from a locally running CLion – Full Remote mode (when you build, run and execute remotely) and 2 options for a remote debug (when only the debugging is done on a remote host).

More opportunities in CMake

CMake is known to be the first-class citizen project model in CLion. Many CLion users rely on it and some users have even converted their projects to CMake to be able to work in CLion. We very much appreciate this strong support, and in this release we have addressed two of the biggest shortcomings with the CMake integration in CLion.

One way we have addressed this is, of course, with the Ninja generator! Moreover, it’s now possible to use any available generator in CMake. Just pass it to the CMake options in the CMake Profiles settings:

The implementation is based on the CMake File API and, as such, is available when CMake 3.15 or higher is used.
We’d like to thank the many EAP users who gave it a try so soon after the feature was released. The feedback we got has helped us address a lot of the issues before the official release.

Another issue we wanted to address was the missing ability to configure some CMake settings globally for newly created projects in CLion. For example, a template for the generation path or some environment settings. Now you can do it with CMake Defaults! Use File | Other Settings | Preferences/Settings for New Projects…

And finally, we addressed another unpleasant issue in this release – if some CMake configurations are invalid and fail to reload, CLion won’t fail now but instead it will successfully reload all possible valid configurations. The typical use case for this is when you don’t have your remote configuration currently connected and there are several local configurations which you’d like to reload. Previously, the whole reload process would simply fail, but now the local configurations will be reloaded successfully.

Switching between Header/Source files

To switch between header and source files, CLion now offers a more effective and more accurate heuristics-based action called Go to Header/Source. Use it instead of the more general IntelliJ-platform Go to Related Symbol action.

The new action tries to locate the single destination file, and if it fails in 500 ms, then it shows an interactive popup where the new items are added (and more importantly are calculated in the background, so no UI freezes!). Then, you can select where you want to navigate to.

The Go to Header/Source search relies on several heuristics, for instance, the most recently switched file is always at the top of the list, and the file with a matching name from the same directory has priority next.

There is only one limitation you have to keep in mind for now – the search is currently limited to direct includers/includees, as this helps to avoid interference from the same symbols from different targets.

Code coverage

While this release was mostly focused on bugs, technical debt, and performance challenges, a few features have still made it through. Code coverage – one of the most top-voted requests in our issue tracker – was addressed by adding integration with llvm-cov/gcov tools.

You can run unit tests and regular configurations with Coverage, just don’t forget to pass the special coverage compilation options. This has to be done manually, as CLion won’t willingly modify your CMake files and compilation options.

The results of the measurements can be checked in a separate Coverage tool window, or it can be done right in the editor – the coverage is indicated with color in the left-hand gutter.

Read more details in our webhelp.

C++20’s Concepts

During the last couple of release cycles, we were experimenting with our Clangd-based language engine. The idea was to merge another experimental branch – Saar Raz’s clang branch with Concepts support – and build a few unique features on top of it. The idea was first discussed when we met Saar at the Core C++ conference in Tel Aviv, in May 2019, and now with CLion 2019.3, we are ready to deliver the results of this collaboration.

In CLion, the Clangd-based engine now assists with parsing and highlighting C++20’s Concepts properly. There are also a few code checks from Clang, and an Unused concept inspection implemented by the CLion team.

Still, the most impressive work was done in code completion, as CLion can now complete template type parameters that are constrained, as well as types constrained by std::is_base_of<MyBase, T>, std::is_same<Other, T> and same_as<T, U>:

Besides this, there is support for Rename refactoring, Go to Definition, and Find Usages navigation actions. You can find more samples and learn about how to enable C++20’s Concepts support in the compiler in our dedicated blog post.

We’d like to thank Saar Raz for his fantastic work in Clang and his productive collaboration with our team!

Other fixes and improvements

The Spell Checker is an essential part of the IDE, which helps keep your comments, string literals and in-code documentation correct and readable. In CLion 2019.3, it is able to spell check CMake files and Doxygen comments:

In addition to WSL, CLion now also supports WSL2. The configuration process in the IDE has stayed the same, just keep in mind that there are some differences in the user experience between these two subsystems.

A new inspection virtual functions called from constructors or destructors was added to catch situations where virtual functions might have access to resources that are not yet initialized or that have already been destroyed:

Microsoft formatting and naming rules were added as a predefined code style option, enhancing the list with Google, LLVM, Qt, GNU, Stroustrup, and other styles.

Since CLion is based on the IntelliJ Platform, there are also VCS improvements and dozens of UI issues resolved. For those of you who use CLion as a Rust IDE, we are happy to share with you that the IntelliJ Rust plugin has had a massive update (we plan to dedicate a separate blog post to it, so stay tuned!).

And that’s it! Hopefully you are not tired from all the reading and are excited to give the new release a try now! We’d love to hear any feedback you have for us on this release!

DOWNLOAD CLION 2019.3

Your CLion Team
JetBrains
The Drive to Develop

While CLion and all our other JetBrains IDEs were making the transition from version 2019.2 to version 2019.3, the IntelliJ Rust team has been busy making important updates to the plugin. In this post, we would like to give a summary of all the features that have been added over the last few months.

• Cfg attributes support
• Include! macro support
• New features of the experimental macro expansion engine
• Other improvements

Cfg attributes support

One of the major updates for IntelliJ Rust is the initial support for cfg attributes. Now, the conditionally disabled blocks are excluded from name resolve and code analysis and are grayed-out in the editor.

At the moment, the plugin only recognizes a limited set of cfg options – other options, including test, are still considered unknown.

Cargo features declared in the project’s dependencies are supported as well, and handling workspace features defined in your Cargo.toml is a work in progress.

As a handy bonus, the plugin provides completion inside cfg attributes to help you quickly fill them in:

Include! macro support

A few revisions back, IntelliJ Rust started to support three common uses of include!: you can pass string literals, concat!, env!("OUT_DIR"), and combinations thereof as input arguments and get full code insight in both the including and included file.

For IntelliSense to work correctly, the include! call should be located in a module (not inside a function).

When you include files using env!("OUT_DIR"), code insight has to work on the code generated at compile time. Currently, you need to manually enable this feature by setting org.rust.cargo.fetch.out.dir in Maintenance (Ctrl+Shift+Alt+/ on Windows/Linux, ⌥⇧⌘/ on macOS) | Experimental Features:

This functionality is disabled by default due to an expensive side effect from the command that is used for retrieving the OUT_DIR variable, cargo build --build-plan. On the next build, this command forces the whole project, including all the dependencies, to recompile.

New features of the experimental macro expansion engine

The plugin’s experimental engine for macro expansion gets more and more features with each release. Just a quick reminder: to turn it on, go to Settings | Languages & Frameworks | Rust, and change the Expand declarative macros option.

The experimental engine provides code insight for macro calls, and it now covers the cases when your macros generate modules and implementations. The generated blocks are properly highlighted, and you get completion and navigation inside the generated elements:

Also, you can use Type Info (Ctrl+Shift+P on Windows/Linux, ⌃⇧P on macOS) and Extend Selection (Ctrl+W on Windows/Linux, ⌥↑ on macOS) in macro calls. Both actions work as they would if they were applied to regular out-of-macro code:

And in addition to this, you can view macro-generated items in the Structure popup (Alt+7 on Windows/Linux, ⌘7 on macOS):

As a part of these improvements, the plugin now takes arbitrary macros into account when performing type inference. Previously, only the top-level items and certain commonly used std macros were processed correctly, causing a false-positive “Type mismatch” in some cases.

Not only does the experimental engine bring more functionality to macro expansion, but it also consumes a lot less memory and works significantly faster than the default engine. Performance improvements, especially those affecting name resolution and type inference, have resulted from the major rework of the plugin’s cache subsystem.

Other improvements

When code generating actions and quick-fixes (like Implement members, Specify type explicitly, or Add remaining patterns) produce symbols that require additional imports, you no longer need to call Import manually. This handy quick fix now works automatically as you type:

New interactive inlay hints can help you navigate through complex declarations even when they include type aliases for enums and structs. Hover the mouse over a hint with the Ctrl key pressed to unfold the type and choose the element you want to jump to:

Now that code coverage is available in CLion, you can use it for your Rust code as well. The implementation of coverage analysis is based on the grcov tool (which the plugin will prompt you to install).

There are also a few enhancements for the toml support provided by the IntelliJ TOML plugin. For example, the paths in Cargo.toml are now equipped with completion, navigation, and certain refactorings:

____________

That’s it for the recent updates in IntelliJ Rust! If you have any questions, please ask them in the comments below or ping the team in gitter. For bug reports and feature requests, don’t hesitate to create tickets in the plugin’s issue tracker.

Thank you for reading and stay tuned!

DOWNLOAD CLION 2019.3

Your Rust Team
JetBrains
The Drive to Develop

Last week we released CLion 2019.3. Unfortunately, it was affected by several unpleasant issues. We’ve investigated all the reports from our users and promptly addressed the discovered problems.

CLion 2019.3.1 (build 193.5233.144) is now available for download from our website, via the Toolbox App, or via snap (for Ubuntu). A patch update will be available shortly.

DOWNLOAD CLION

This update contains the following fixes:

• Language engine:
  • A problem with randomly occurring red code and an incorrect suggestion to import user classes from the std namespace turned out to be an issue with the missing include file (CPP-18270 and the related CPP-18246, CPP-18247, CPP-18280).
  • Completion of standard library symbols in the global namespace is now working correctly in Clangd (CPP-18249).
  • Various fixes preventing the Clangd-based engine from crashing were introduced.
• Remote development:
  • A mechanism of synchronizing headers in background was recently enabled by default, and it turned out to cause massive delays on loading CMake projects in many cases (e.g. CPP-18277). We’ve reverted it for now until we can come up with a better solution.

Our team appreciates all the valuable feedback the community provided after the release and sincerely apologizes for any inconvenience caused.

Your CLion Team
JetBrains
The Drive to Develop

This year’s third big update – CLion 2019.3 – has landed, along with its first bug-fix update, 2019.3.1. If you haven’t yet updated your CLion, now is a great time to do so.

Before moving forward on to 2020, we’d like to give our most sincere thanks to our Early Access Program users! Without you we wouldn’t be able to catch so many annoying issues affecting the wide variety of C++ environments, and make CLion as good as it can be!

Special thanks

We’d like to present our most active EAP evaluators with a full 1-year subscription to CLion, which they can use to buy a new subscription or extend a current one. Feel free to pass the code to a friend or colleague! So our special thanks go to:

• Roman Popov
• Maxim Yanchenko
• Miha Rozina
• Roland Illig

You will receive a personal email with details on how to claim your license. (If for some reason you do not get an email from us within a week, ping us here in the comments!)

Roadmap: CLion in 2020

Let’s first look at the main priorities we have for 2020. Actually, they haven’t changed much since 2019. We are still focusing on:

1. Performance and responsiveness: continue eliminating UI freezes and working on large architectural changes to make global improvements to CLion’s performance.
2. Clangd: make the engine more stable and eliminate crashes, move as many IDE functions as possible to Clangd, and add new language features on top of the Clangd-based language engine.
3. Project model: work on native support for Makefiles, consider other build systems such as Bazel, and work towards a project model API in CLion.
4. Embedded: double the efforts we put into the embedded development support and work on more essential features in this area.

Taking on 2020.1

Here are the main tasks we’ve set for the next release, CLion 2020.1, which should be out around late March.

• Clangd-based engine:
  • Improve engine stability, eliminate crashes, investigate memory usage.
  • Fix Clangd code completion issues.
  • Automatically use the .clang-tidy config file in the project directory, if any.
  • Move Data Flow Analysis to Clangd to improve the performance.
• C++ support:
  • Initial CUDA support.
  • Enhance typing in the multiline macros, and add other performance and responsiveness improvements.
  • Introduce default values for Change Signature refactoring.
• Project Models:
  • Native Makefiles support.
  • Polish the CMake File API integration (including recompiling a single file).
• Debugger:
  • Debugging of Core dumps (CPP-7977).
  • Input redirection (CPP-3153).
• Embedded development:
  • IAR and armcc toolchain support (CPP-14192).
• Various fixes and enhancements:
  • Fix bugs and freezes related to remote toolchains.
  • Automatically add required compilation flags for sanitizers/coverage.

This is what’s going to keep us busy. If you have any new feature requests, please send them to our tracker. We’re listening!

Your CLion Team

JetBrains
The Drive to Develop

A new bug-fix update for the recently released CLion 2019.3 is now available for download! You can get CLion 2019.3.2 (build 193.5662.56) from our website, via the Toolbox App, or as a snap package (for Ubuntu). A patch update will be available shortly.

DOWNLOAD CLION

In this update, Clangd-based code highlighting was improved:

• override and final keywords are now correctly highlighted:
  
• In C11 code, when integers have suffixes with mixed lower/upper cases, the highlighting no longer fails:
  
• std namespace usages from concepts library are now highlighted correctly.

Clangd-based code completion also got a few enhancements:

• When completing a function with the default arguments, the cursor is placed inside the parentheses, not behind the closing parenthesis.
• When generating function implementations via code completion, CLion now generates correct code in the proper context (CPP-18384).

Code coverage, which we introduced in v2019.3, has been updated to prevent situations when it runs out of memory on large test suites.

Thank you for your feedback on CLion’s WSL/WSL2 support! Taking it into account, we have made some updates to give you these improvements:

• Indexing performance is improved thanks to more accurate work with the WSL file system.
• An issue with detecting an openSUSE-Leap-15-1 distribution is fixed.

The following issues are also fixed:

• Commands are now formatted correctly in GDB when using Arabic, Hebrew, or Hindi locales making the debugger work correctly.
• External Tools for Custom Build Targets are now stored in project configs instead of system configs (where they cannot be shared in a VCS).

The full release notes are available here. If you are interested to know what’s coming to CLion in 2020, check out our roadmap.

DOWNLOAD CLION

Your CLion Team
JetBrains
The Drive to Develop

One of the common questions we get is why there is no Docker integration in CLion? In fact CLion works very nicely with Docker! There might not (yet) be a specific, “use Docker”, button – but setting it up yourself is actually quite easy and straightforward – even if you’re a Docker newbie!

Read on if you prefer written instructions, or watch this video with the same content:

1. Why use Docker?
2. Getting Docker
3. Creating a Docker container for use with CLion.
4. Using the Remote Development workflow with Docker
5. Changing the Docker environment
6. Good luck getting Dockerized!

Why use Docker?

But why would you want to do this at all? Docker is not just the latest trend, but it represents a new way of setting up different environments in a quick, easy, reproducible and reliable way – that is easy to share, say, in version control.

Common uses for C++ developers are: working with multiple toolchains (especially different versions of the same compiler – which can be very tricky to maintain otherwise), working with cross-compilers for different platforms, or even just using a single environment but making it easy for everyone on your team to get the same environment quickly and easily (and keep it updated).

Docker is lighter-weight than a VM, but gives you essentially the same levels of isolation. It sounds complex to set-up, but one of the surprises for many is just how easy it is to get going.

Getting Docker

If you don’t already have it you’ll need to install the Docker Engine. This is fairly straightforward, although there may be a few extra steps, depending on your platform. The docs are excellent throughout, and the installation instructions are no exception – so check them out for your platform.

Creating a Docker container for use with CLion.

Docker containers are described in Dockerfiles. These look like simple scripts, but have a few special properties that make them a bit special.

First, you can refer to a “base image”, which is a prebuilt container, usually available via a docker registry, which does a lot of the heavy lifting. We’ll use a Ubuntu base image to give us a common platform to start with – but other OS images are available. E.g.

FROM ubuntu:18.04

Secondly, each line in a Dockerfile is executed on what Docker calls a layer. Each layer is immutable, once created – so any mutations on the layer above can be easily, and cheaply, rolled back – without having to recreate all the layers beneath.

That’s one of the things that makes Docker such a fast and productive environment once you get used to it. We won’t go into this in any more depth, here. It’s worth going through the introductory docs if you want to get more of a feel for it.

We’ve created a reference Dockerfile for you to get started. It should be fairly obvious how to change this to meet your needs.

Mostly you’ll change the apt-get part, which should be immediately familiar if you’ve used Ubuntu, before. Of course if you change the base image you may need to use a different approach to getting dependencies there. The point is it is just using the base image OS’s package manager (within Docker’s RUN command).

You may also be able to get (or create yourself) a base image with all the dependencies already set up.

RUN apt-get update \
  && apt-get install -y ssh \
    build-essential \
    gcc \
    g++ \
    gdb \
    clang \
    cmake \
    rsync \
    tar \
    python \
  && apt-get clean

The Dockerfile then sets up SSH, so CLion can connect into it, and creates a user for CLion to use.

RUN useradd -m user && yes password | passwd user

Usually the credentials needn’t be too obscure, but of course you can change them if you need to – or use another way (beyond the scope of this intro) to specify the details without mentioning them in the Dockerfile.

At the top of the Dockerfile, in the comments, are the three commands you’ll need to execute to build and run this Docker container.

The first builds the container:

docker build -t clion/remote-cpp-env:0.5 -f
Dockerfile.remote-cpp-env .

This will take a few minutes to run, as it downloads the Ubuntu image (whether or not you are already running on Ubuntu), “installing” that into the first layer, installing all the dependencies (that apt-get line), setting up SSH and creating the user! Given all that it is surprisingly fast (and you should only have to do this once).

Once built you can run the container, using the next line:

docker run -d --cap-add sys_ptrace -p2222:22 --name clion_remote_env clion/remote-cpp-env:0.5

The -d runs the container as a daemon, so control returns back to you.
--cap-add sys_ptrace adds the ptrace capability, which is necessary for debugging. Docker containers are usually very minimal, by default, so you sometimes need to enable fundamental things.

-p2222:22 specifies a port mapping. Port 22 (the default SSH port) inside the container is mapped to outside the container as port 2222 on the host environment.

There’s nothing special about 2222. Doubling up, or multiplying by 10 are common ways of expressing mapped ports, but you could specify any available port number, here. That can be useful if you intend to run multiple containers side-by-side (e.g. to support alternate toolchains).

Whatever port number you chose, since it’s only temporarily mapped, and may be reused, it’s usually worth clearing any cached SSH keys:

ssh-keygen -f "$HOME/.ssh/known_hosts" -R [localhost]:2222"

Don’t worry if that tells you it couldn’t find any – likely the first time.

So now the Docker container is up and running, ready with your toolchain installed. All that’s left is to get CLion to use it.

Using the Remote Development workflow with Docker

Since we set-up SSH in our container we can connect into it using CLion’s standard Remote Development features. See our help pages for full details on setting up Full Remote Mode.

In short, you should add a new Toolchain entry in settings under Build, Execution, Deployment as a Remote Host type.

Then click on the in the Credentials section and fill out the SSH credentials we set-up in the Dockerfile (Host: localhost, Port: 2222, User name: user, Password: password).

Finally, add a CMake profile that uses this toolchain and you’re done. If you want more fine grained control over the paths used inside the container take a look at the Deployment settings page.

Either way, once you commit (Apply and/ or OK) out of settings, and wait for the CMake profile to load, and files to transfer, you can then select the CMake profile from the Run Config drop-down, and your code will now be compiled, run and debugged, within the container using the specified toolchain.

If the container has an earlier version of CMake than your local project (and you created the project, first, locally) then you may need to set the CMake version back at the top of the CMakeLists.txt file.

You could also get a later version of CMake in the Dockerfile but that’s beyond the scope of this post.

Changing the Docker environment

If you need to make changes to the container you may need to re-run the build step, as well. Consult the Docker docs to be sure, as it’s not always obvious whether a change has taken effect, due to Docker’s extensive caching (usually a good thing).

If you do rebuild you’ll probably also have to reload the CMake project, as well.

Good luck getting Dockerized!

That should be all you need to get started. Be sure to read the Docker docs to get the most out of Docker, itself. And check out the Remote Development docs in the CLion help for a few more details that may be helpful, too.

A new bug-fix update, CLion 2019.3.3, is now available for download! You can get build 193.6015.37 from our website, via the Toolbox App, or as a snap package (for Ubuntu). A patch update will be available shortly.

DOWNLOAD CLION

Here are the main highlights of the update:

• Refactorings
  • Fix for the incorrect macro inlining (CPP-18442).
  • A regression in Extract Method has been fixed (CPP-18640).
• Toolchains
  • Support for the /std:c++latest flag when using Microsoft Visual C++ Toolchain (CPP-16330).
  • The $PROJECT_NAME$ macro is now available (and refers to the CLion’s project name) in path-strings in configuration files for the project. This allows, among other things, the specification of a default CMake build directory outside of the project root (CPP-18172):
    
• Editor
  • Raw strings are now recognized as literals in macro calls, thus eliminating false positives in the analysis.
  • Incorrect designated initializer highlighting has been fixed (CPP-18486).
• Because of the exception failing, the Kotlin/Native plugin was blocking unit tests in CLion from running (CPP-18169). This issue has been resolved and the tests now run as expected.

We’ve also made various small improvements to name hints, concepts and Clangd-based code completion.

The full release notes are available here. If you are interested in learning about what’s coming to CLion in 2020, check out our roadmap. The CLion 2020.1 EAP will start soon – stay tuned!

DOWNLOAD CLION

Your CLion team
JetBrains
The Drive to Develop

Are you interested in embedded development? In this guest blog post Nick Brook, founder at NRB Tech, shows how to use CLion for nRF52.

IoT consultant and founder at NRB Tech. Nick founded NRB Tech in 2018 to build useful and sustainable IoT products through a combination of in-depth hardware, software and user experience expertise.

Nordic’s nRF52 series of Bluetooth Low Energy System-on-Chips (SoCs) are versatile and widely used in IoT products, supporting many different applications. Nordic provides a very complete SDK which contains many example applications and good documentation, making it easy to get started and build IoT devices. Some of the example projects available in the SDK include:

• Beacons
• Blood pressure monitoring
• Cycling speed and cadence
• Glucose monitoring
• Heart rate
• HID Keyboard + Mouse
• Running speed and cadence
• Many other technical example projects

These provide great starting points to develop a Bluetooth Low Energy device of your own.

At NRB Tech we use the Nordic nRF52 series SoCs to build products such as AirTurn’s range of foot pedals, which act as a keyboard, mouse, MIDI device, or use a proprietary protocol.

Bluetooth products are often a combination of a low power device and an App. It’s useful to be able to share code across those platforms, so that you can write and test the code just once for both the firmware and the App.

CLion is a great IDE for C and embedded development, and CMake provides many advantages such as the ability to create libraries that can be shared across platforms and to integrate those libraries into an application easily. However, the nRF52 SDK does not support development with CMake/CLion out of the box, but the Nordic nRF5 Mesh SDK does use CMake – although it does not support external projects.

So we built nRF5-cmake-scripts, which uses the mesh SDK scripts and provides CMake functions to add your own targets. It also makes adding the DFU bootloader very simple and provides many macros for adding the nRF5 SDK libraries to your project as you need them. Let’s set up an example project, using CLion as our IDE.

1. Setting up.
2. Creating a nRF52 project.
3. Debugging in CLion.

Setting up

This tutorial assumes you are using an nRF52 DK. If you are using different nRF5 hardware, you’ll need to modify the variables at the top of the root CMakeLists.txt later in the tutorial.

You will need the following dependencies:

• Nordic command line tools (nrfjprog and mergehex) by Nordic Semiconductor – Wrapper utility around JLink.
  • This also includes the JLink installer – install it.
• Python 3.
• Nordic nrfutil by Nordic Semiconductor – a utility for generating DFU packages.
  • After installing Python, install using pip install nrfutil.
• ARM GNU Toolchain by ARM and the GCC Team – a compiler toolchain for embedded ARM chips.
  • On a Mac, this can be installed with homebrew:
    

    brew tap ArmMbed/homebrew-formulae
    brew install arm-none-eabi-gcc

  • On other platforms, you can download it from the GNU-ARM toolchain page.
• git – A version control system.
• CMake – A build tool.
• On Mac and Linux, your PATH is probably automatically configured correctly. But if some executables cannot be found, then edit your ~/.profile file and add export PATH="<additional paths, semicolon separated>;$PATH".
• On Windows you will need to ensure that all binaries are in your PATH (instructions for editing). Your PATH additions might look something like this:
  

  C:\Program Files (x86)\GNU Tools Arm Embedded\9 2019-q4-major\bin
  C:\Program Files\Nordic Semiconductor\nrf-command-line-tools\bin
  %USERPROFILE%\AppData\Local\Programs\Python\Python37\Scripts
  C:\Program Files\Git\cmd
  C:\Program Files (x86)\SEGGER\JLink

Creating a nRF52 project

Once the dependencies have been installed, clone the base project in a terminal/command window to set up the project structure:

git clone --recurse-submodules https://github.com/NRB-Tech/nRF5-cmake-scripts-example-base.git .

Run a script to get the project ready for your own use (on Windows, run in git bash by right clicking in the directory > “Git Bash here”):

./cleanup.sh

Then, copy the example CMakeLists.txt as recommended in the nRF5-cmake-scripts readme:

cmake -E copy nRF5-cmake-scripts/example/CMakeLists.txt .

Note: You may also need to edit some of the variables in this file for your platform, such as by setting NRFJPROG, MERGEHEX, NRFUTIL and PATCH_EXECUTABLE manually if they are not in your PATH.

At this point, you can open the project in CLion. Build the download target to fetch the dependencies.

Using the Terminal tab in CLion, copy over some files from an SDK example project:

cmake -E copy toolchains/nRF5/nRF5_SDK_16.0.0_98a08e2/examples/ble_peripheral/ble_app_template/pca10040/s132/armgcc/ble_app_template_gcc_nrf52.ld src/gcc_nrf52.ld
cmake -E copy toolchains/nRF5/nRF5_SDK_16.0.0_98a08e2/examples/ble_peripheral/ble_app_template/pca10040/s132/config/sdk_config.h src/

Add a file src/main.c, and then add some source code. Here we add some simple code to log a message.

#include "nrf_log_default_backends.h"
#include "nrf_log.h"
#include "nrf_log_ctrl.h"
int main(void) {
    ret_code_t err_code = NRF_LOG_INIT(NULL);
    APP_ERROR_CHECK(err_code);
    NRF_LOG_DEFAULT_BACKENDS_INIT();
    NRF_LOG_INFO("Hello world");
    while(true) {
        // do nothing
    }
}

Create an src/app_config.h file to override some of the default configurations in sdk_config.h:

#define NRF_LOG_BACKEND_RTT_ENABLED 1 // enable rtt
#define NRF_LOG_BACKEND_UART_ENABLED 0 // disable uart
#define NRF_LOG_DEFERRED 0 // flush logs immediately
#define NRF_LOG_ALLOW_OVERFLOW 0 // no overflow
#define SEGGER_RTT_CONFIG_DEFAULT_MODE 2 // block until processed

We are going to include the DFU bootloader too, so we need to generate keys. In the terminal/command prompt:

nrfutil keys generate keys/dfu_private.key
nrfutil keys display --key pk --format code keys/dfu_private.key --out_file keys/dfu_public_key.c

Now we need to create a file src/CMakeLists.txt to build our targets:

set(NRF5_LINKER_SCRIPT ${CMAKE_CURRENT_SOURCE_DIR}/gcc_${NRF_FAMILY})
# DFU requirements
# List the softdevice versions previously used, or use FALSE if no previous softdevices
set(PREVIOUS_SOFTDEVICES FALSE)
# Set the location to the DFU private key
set(PRIVATE_KEY ${CMAKE_CURRENT_SOURCE_DIR}/../keys/dfu_private.key)
set(PUBLIC_KEY ${CMAKE_CURRENT_SOURCE_DIR}/../keys/dfu_public_key.c)
# Set the App validation type. [NO_VALIDATION|VALIDATE_GENERATED_CRC|VALIDATE_GENERATED_SHA256|VALIDATE_ECDSA_P256_SHA256]
set(APP_VALIDATION_TYPE NO_VALIDATION)
# Set the Soft Device validation type. [NO_VALIDATION|VALIDATE_GENERATED_CRC|VALIDATE_GENERATED_SHA256|VALIDATE_ECDSA_P256_SHA256]
set(SD_VALIDATION_TYPE NO_VALIDATION)
# The bootloader version (user defined)
set(BOOTLOADER_VERSION 1)
# The DFU version string (firmware version string)
set(DFU_VERSION_STRING "${VERSION_STRING}")
# Set the target name
set(target example)
# add the required libraries for this example
nRF5_addLog()
nRF5_addSeggerRTT()
nRF5_addAppError()
# include files
list(APPEND SOURCE_FILES main.c)
list(APPEND INCLUDE_DIRS "${CMAKE_CURRENT_SOURCE_DIR}")
nRF5_addExecutable(${target} "${SOURCE_FILES}" "${INCLUDE_DIRS}" "${NRF5_LINKER_SCRIPT}")
# make sdk_config.h import app_config.h
target_compile_definitions(${target} PRIVATE USE_APP_CONFIG)
# Here you can set a list of user variables to be defined in the bootloader makefile (which you have modified yourself)
set(bootloader_vars "")
# add the secure bootloader build target
nRF5_addSecureBootloader(${target} "${PUBLIC_KEY}" "${bootloader_vars}")
# add the bootloader merge target
nRF5_addBootloaderMergeTarget(${target} ${DFU_VERSION_STRING} ${PRIVATE_KEY} ${PREVIOUS_SOFTDEVICES} ${APP_VALIDATION_TYPE} ${SD_VALIDATION_TYPE} ${BOOTLOADER_VERSION})
# add the bootloader merged flash target
nRF5_addFlashTarget(bl_merge_${target} "${CMAKE_CURRENT_BINARY_DIR}/${target}_bl_merged.hex")
# Add the Bootloader + SoftDevice + App package target
nRF5_addDFU_BL_SD_APP_PkgTarget(${target} ${DFU_VERSION_STRING} ${PRIVATE_KEY} ${PREVIOUS_SOFTDEVICES} ${APP_VALIDATION_TYPE} ${SD_VALIDATION_TYPE} ${BOOTLOADER_VERSION})
# Add the App package target
nRF5_addDFU_APP_PkgTarget(${target} ${DFU_VERSION_STRING} ${PRIVATE_KEY} ${PREVIOUS_SOFTDEVICES} ${APP_VALIDATION_TYPE})
# print the size of consumed RAM and flash - does not yet work on Windows
if(NOT ${CMAKE_HOST_SYSTEM_NAME} STREQUAL "Windows")
    nRF5_print_size(${target} ${NRF5_LINKER_SCRIPT} TRUE)
endif()

Reload the CMake project (Tools | CMake | Reload CMake Project), then we are ready to build and run our example. First, build the START_JLINK_RTT target to open an RTT console, then build the flash_bl_merge_example target. You should see the “Hello world” log output in the RTT console! From here you can add source code and include SDK libraries with the macros provided in nRF5-cmake-scripts/includes/libraries.cmake.

To debug this code, we need to do a little more work to set up CLion.

Debugging in CLion

First, we need to add a toolchain to use the ARM debugger client. In CLion Preferences/Settings | Build, Execution, Deployment | Toolchains, create a new toolchain named arm-none-eabi and set the Debugger to arm-none-eabi-gdb:

Then we need to use that toolchain for our CMake profile. In CLion Preferences/Settings | Build, Execution, Deployment | CMake set the Toolchain to arm-none-eabi:

Next we just need to create the build configuration for debugging. On the top right of the CLion window, click the configuration drop down and choose Edit Configurations. Then Add a new Embedded GDB Server configuration:

Configure as shown:

1. Set a name.
2. Share through VCS to share this configuration with other CLion users of your project.
3. Select the flash_bl_merge_<target> target.
4. Select your executable.
5. Set “Download executable” to “None.”
6. Set ‘target remote’ args to tcp:localhost:2331.
7. Set GDB Server to
   • Mac: /usr/local/bin/JLinkGDBServer.
   • Windows: C:\Program Files (x86)\SEGGER\JLink\JLinkGDBServerCL.exe.
   • Or the appropriate path for your system.
8. 1. Set GDB Server args to -device nrf52 -strict -timeout 0 -nogui -if swd -speed 1000 -endian little -s.

Now we can build or debug this target, which will build the firmware and bootloader then flash to the device. When debugging, if your breakpoint is not hit when the debugger starts, just press the reset button and continue:

You can also view the state of peripherals on the device when debugging. When debugging, click the Peripherals tab and click “Load .svd file”:

Browse to toolchains/nRF5/nRF5_SDK_16.0.0_98a08e2/modules/nrfx/mdk and select the .svd file for your hardware (for nRF52832 use nrf52.svd), then select the peripherals you want to monitor. When the debugger is paused you will then be able to inspect the values of peripheral registers:

This tutorial was originally posted at NRB Tech blog.

Now you are ready to give it a try!

DOWNLOAD CLION

Hi,

We’ve got a lot planned for 2020 and 2020.1 and now it’s time to start our regular Early Access Program!

EAP builds are free and give you a preview of the upcoming changes and enhancements. They might not be stable and might contain functionality that doesn’t make it to the final release. And if you decide to try these builds, please, inform us of any issues you run into or any inconveniences you experience as early as possible, so we have time to investigate and can try to address them before the release.

You can download the first EAP build (201.4515.29) from our site, via the Toolbox App, or as a snap package (for Ubuntu) and install it side by side with the stable release build.

DOWNLOAD CLION 2020.1 EAP

• Clang-based tools in CLion:
  • Clangd-based code completion improvements.
  • ClangFormat improvements.
  • Clang-Tidy improvements.
  • Data Flow Analysis on Clang.
• Debug:
  • Debugging of custom targets.
  • Debugger for the Visual Studio C++ toolchain.
• Editor:
  • Quick Documentation on mouseover.
  • JetBrains Mono.
  • IntelliJ Light.
• Other improvements.

Clang-based tools in CLion

Clangd-based code completion

Clangd-based code completion, introduced in CLion 2019.3, has been significantly improved thanks to dozens of various issue fixes, for example:

• Missing keywords, like switch, try, catch, and others, were added to the completion lists.
• Operators have been added to the completion list.
• Completion after a dot has been added in structure initialization:

ClangFormat

If you turn ClangFormat on in CLion settings, then CLion will use it not only for formatting the code or the reformat action, but also for indenting after Enter or Backspace are pressed. This makes the indentation more accurate.
Besides, if you enable ClangFormat on the project without .clang-format config file, CLion will suggest creating one for you. The configuration will be similar to the one you currently have in CLion’s own code style settings. You may refuse, then ClangFormat will be enabled with the default LLVM style.

Additionally, we are now working on enabling ClangFormat by default in cases where a ClangFormat config file is found in the project root. This change should arrive later during this EAP program.

Clang-Tidy

Similarly, when a .clang-tidy config file is detected in the project, CLion now turns off the use of the IDE settings for Clang-Tidy automatically. If you prefer the previous behavior, uncheck the Prefer .clang-tidy files over IDE settings in Settings/Preferences | Editor | Inspections | C/C++ | General | Clang-Tidy.

Data Flow Analysis

CLion’s Data Flow Analysis (DFA) is a set of powerful checks that most compilers don’t do. These checks have been available in CLion from the very early versions of the product. They analyze how the data flows through your code and detect potential issues based on that. For example, DFA detects that the second condition in the second if clause is always true when reached in the code sample below:

DFA can also detect endless loops, missing return statements, infinite recursion, and more.

DFA can catch lots of potentially serious problems. However, it requires very accurate code parsing and resolve, and it can take a significant amount of time. Especially, when the underlying resolve is slow. That’s why in 2020.1 we’ve moved DFA to a Clangd-based engine. This is still a work in progress, and many known issues are linked to the parent ticket CPP-17578 (like, for example, some issues with DFA when macros or templates are used, or the issue with the inspection settings CPP-17707). Feel free to report any new issues you find to our issue tracker.

Debug

Debugging of custom targets

Remote GDB Server and Embedded GDB Server configurations allow you to debug your application on a remote host or at the microcontroller from the CLion running on your local machine. Previously, only CMake projects were supported as the configuration worked only with the CMake targets. Now we’ve also added custom targets support there. For example, if you work with the embedded project using Makefiles as a project model, you can now simply follow our workaround via the compilation database to get a Makefiles project to work in CLion and then use the custom targets to build your project locally and debug remotely on a microcontroller.

Note, if you have already created any of these configurations in CLion v2019.3 or earlier, when you first open such a project in 2020.1, CLion will store previous Run/Debug Configuration settings in the projectFilesBackup directory in the project folder. You’ll be notified about this in the editor:

New EAP build also improves the Embedded GDB server workflow. CLion now stops the debugger correctly if you close your project. Additionally, the Embedded GDB Server configuration now automatically uses the configured Reset command after the executable has been downloaded.

Debugger for the Visual Studio C++ toolchain

Some time ago we bundled the LLDB-based debugger that is suitable for debugging applications compiled with the Microsoft Visual Studio C++ toolchain. This is an experimental debugger developed by the JetBrains team, so in its early stages it was added to CLion as an experimental feature, but disabled by default.
Now, the debugger for the Microsoft Visual C++ toolchain is enabled by default! Which means that for this toolchain it will be the default debugger and you can start using it right away! Still, to enable bundled support for native visualizers, use Preferences/Settings | Build, Execution, Deployment | Debugger Data Views | Enable NatVis renderers for LLDB.
Please share your feedback with us on how the debugger works for your projects in our tracker or here in comments! We’d love to know in which direction you’d like us to further improve it.

Editor

Quick Documentation on mouseover

The Quick Documentation popup works as a universal tool to get more information about a code element that is under the caret. Not only does it preview the code documentation, but it also provides information about function signature, inferred types, and macro replacement. And now in 2020.1, it’s available on mouseover!

The behavior can be controlled controlled using the setting in Editor | General | Other | Show quick documentation on mouse move.

JetBrains Mono

You’ve probably already noticed that the default font in the editor has changed! We’re excited to introduce our new open source font – JetBrains Mono. This font was created in pursuit of the very ambitious goal of making working with code more comfortable for everyone. Try it out in this EAP build and let us know whether we are getting close to achieving it!

IntelliJ Light

The light theme is now unified for all operating systems under the name IntelliJ Light. If you are experiencing any issues with it, you can roll back to the previous look and feel in Settings (select Classic Light).

Other improvements

The first CLion 2020.1 EAP build comes bundled with CMake v3.16.

CUDA users will be happy to learn that we’ve fixed the long-standing issue with the launch of CMake CUDA targets that used to run a wrong binary (CPP-10292). We have more improvements planned for CUDA, so stay tuned!

Code Coverage was introduced in CLion 2019.3 and it now works for out of source builds.

Several VCS improvements from the IntelliJ Platform have also been added in this build:

• The branches popup benefits from an explicit search field and incoming (blue) and outgoing (green) commit indicators next to the branch’s name.
• A new, truly interactive Rebase from Here dialog has been introduced.
• New Commit tool window.

You can read more in these IntelliJ IDEA blog posts (1, 2).

DOWNLOAD CLION 2020.1 EAP

Your CLion team
JetBrains
The Drive to Develop

CLion started the 2020.1 EAP program last week with many improvements to Clang-based tooling, the debugger, and the overall editor. This week a new build is available, bringing more sophisticated CUDA support!

You can download the build (201.4865.10) from our website, via the Toolbox App, or as a snap package (for Ubuntu) and install it side by side with the stable release build.

DOWNLOAD CLION 2020.1 EAP

• CUDA support
  • Why CUDA?
  • Start a new project with CUDA
  • How does CLion support CUDA?
  • Known issues and limitations
• Clang on Windows

CUDA support

Why CUDA?

Before jumping into a detailed overview of what’s actually supported for CUDA, let me first briefly elaborate on how we have come to this decision. If you are not really interested in this, feel free to skip directly to the next part.

CLion is a general-purpose cross-platform C and C++ IDE. There are plenty of interesting domains where C and C++ are used as the primary language. A number of global industries, like High-frequency trading (HFT), embedded development, and game development, use C and C++, along with other more specific fields like automated vehicle research, AI, telecommunications, and GPGPU. Because of the limited number of developers we have in the team, it’s hard to cover each and every one of these areas right now. (Believe us, we’d love too!) So we have had to make some difficult choices about what to prioritize.

That’s why we recently analyzed the current state of CLion’s support for various C++ development areas. The main criterion we considered was whether users were able to expect their code to be correctly handled by the IDE, at least from the general C++ perspective. And once that was determined, more specific requests would come into play.

With this framework to guide us, in November 2019 we took a look at various areas where CLion was still weak and realized that CUDA was one where we generally failed to meet our criterion. Taking Qt as a point of contrast, CLion can successfully parse and work with a Qt project. Some Qt specifics might not be taken into account in the refactorings, code generation, and other smart actions, but from a C++ language perspective, they are still correct. With CUDA the situation was different. CUDA C and C++ is essentially C/C++ with a few extensions, and the IDE was not handling these extensions correctly. This resulted in red code, false positives, and other unpleasant consequences that you could encounter as soon as you started using CUDA in CLion, making the IDE completely impossible to use.

That’s why we’ve decided to dedicate some time to fixing these issues with CUDA. Of course, more specific support for specific technologies, be they CUDA, Qt, or others, is also on our roadmap for the future. But for now, our goal is to eliminate the most irritating issues.

Start a new project with CUDA

If you are new to CUDA, we recommend starting by downloading the CUDA Toolkit from the official site and checking out the official documentation. To start a new project in CLion, call File | New Project and select CUDA library or CUDA executable:

The sample CMake and main.cu files will be generated for you:

You may notice new file extensions for source and header CUDA files – .cu/.cuh. They are also available in the new C/C++ file creation dialog and have their own icons:

For CUDA projects, the list of CMake targets in this dialog includes general CMake and CUDA targets (created with cuda_add_executable/cuda_add_library).

How does CLion support CUDA?

Let’s clone the ClaraGenomicsAnalysis project from GitHub and check out what CLion is capable of in terms of CUDA support. Make sure CMake used in CLion knows where to find the CUDA toolchain. For example, you can set CMAKE_CUDA_COMPILER to the nvcc compiler path.

The first thing you’ll notice is that CUDA code, including all CUDA specific extensions, is now parsed and highlighted correctly:

This means code navigation, code documentation, and other code assistance actions work:

Additionally, CLion can complete angle brackets for kernel calls:

Known issues and limitations

First of all, there are some OS-specific details you’ll need to pay close attention to:

• On Windows: CUDA only works with the Microsoft Visual C++ toolchain, and you are required to have x64 cl.exe in your PATH. For this toolchain, CLion bundles the LLDB-based debugger developed by JetBrains, which for the moment might have issues with the CUDA code.
• On Linux: Because of the regression, cuda-gdb can’t be selected in the UI (CPP-18931).
• On macOS: We didn’t test on this platform, as it’s officially no longer supported after v10.13.

Other notable issues for CUDA code include:

• Code insight actions (like Go to Declaration, Rename, or Extract Variable) don’t work inside <<<...>>> (CPP-18722).
• In the alpaka project, CLion fails to collect compiler info, and so red code is present (CPP-18901).
• For CUDA projects, CLion incorrectly parses the compilation database generated by CMake (CPP-18926).
• Coverage, cuda-memcheck, Valgrind Memcheck, and Profiling don’t work properly for CUDA projects, for now at least. This is definitely a feature we are considering to address in future updates.

Clang on Windows

While Clang has been available in CLion on Linux and macOS for quite a long time, certain issues and limitations made it too inconvenient to be practical on Windows. We have now made it possible to use clang-cl in CLion on Windows! All versions from 8.0 on are supported.

You can install it from the LLVM site or along with the Visual Studio tools. When done, select the Visual Studio toolchain in CLion and point to clang-cl.exe in the toolchain settings:

You are now all set up!

Mind you, there is a known issue that causes -T clangcl options not to be picked up by CLion if the bundled CMake is in use while Visual Studio is enabled (CPP-18848).

If you want to find out more, the full release notes are available here.

DOWNLOAD CLION 2020.1 EAP

Your CLion team
JetBrains
The Drive to Develop

A new bug-fix update, CLion 2019.3.4, is now available for download! You can get build 193.6494.38 from our website, via the Toolbox App, or as a snap package (for Ubuntu). A patch update will be available shortly.

DOWNLOAD CLION

Here are the main highlights of the update:

• CMake CUDA targets are now launched from CLion using the correct binary (CPP-10292). If you are interested in more sophisticated CUDA support, please check out the 2020.1 EAP build.
• Google Test support:
  • False errors on Google Test v1.8.1 have been fixed (an error message was produced for INSTANTIATE_TEST_SUITE_P, see CPP-16301).
  • False positive inspection warnings for new MOCK_METHOD macro from Google Test v1.10.0 (CPP-18182).
• Formatter improvements:
  • Reformat Code no longer breaks indentation in an enum when using a comment line (CPP-1836).
• Several Clangd crashes were addressed.

The full release notes are available here.

The CLion 2020.1 EAP is now up and running. The first builds bring CUDA enhancements, Clang-cl support, the ability to debug customer targets, Data Flow Analysis rewritten on Clang, and much more. For more details please see this page.

Your CLion team
JetBrains
The Drive to Develop

What request in our tracker has more than 1000 votes, 370 comments, and 800 watchers? You guessed it: Support Makefile projects. This has been a story of interesting findings, semi-automatic workarounds, and a long battle that we still plan to win! If you’d like to get the latest news on this topic, please read on.

• From past to present: the evolution of project models in CLion
• Support for Makefile projects: How-to
  • Option 1: Compiler wrappers
  • Option 2: LD_PRELOAD
  • Option 3: Parse the output of Make
• Support for Makefile projects: CLion’s prototype
  • What could possibly go wrong?
  • Projects we used for testing
• Call for help!

From past to present: the evolution of project models in CLion

As you know, all work in CLion is done within the context of a project. Projects serve as the basis for coding assistance, bulk refactoring, coding style consistency, and other smart features. To understand the project model, CLion collects not only the list of project files, but also compilation flags, header search paths, and project-model specific variables. The IDE can create several resolve configurations aggregating these parameters, which you can switch in the editor when necessary.

5 years ago CLion was launched with CMake-only projects, and we shared the reasoning behind that decision in our blog. Since then, CMake has been growing steadily in the C++ community and finally overtook Visual Studio to become the most popular project model / build system for C++ development.

However, in the world of C++ there is no single standard project model. There are Makefile projects, qmake, msbuild, Bazel, Scons, and many others. Makefile projects are in the top 3, popular in OSS and embedded projects, and widely used for cross-platform C++ development, which makes them the best candidate to add to CLion.

On our journey to supporting Makefile projects, we’ve taken the following steps:

• Open a folder in CLion. With no project model in place, CLion treats all the code on a very basic level and can’t provide any smart coding assistance (like Go to Symbol or refactorings).
• Compilation database support. This is a truly universal project format, which can be generated from any project model, including any custom one. CLion provides full coding assistance for such projects, and often that’s the easiest way to open an arbitrary project in CLion.
• Support for custom build targets and custom Run/Debug configurations. We added this to enrich the compilation database or folder-based projects experience, as build/clean commands can then be used by CLion and such applications can be run and debugged.

While it’s now possible to build, run and debug any projects (including Makefile-based) in CLion by using Custom Build Targets, it requires an accurate manual setup. The CMake project experience is much better here – CLion automatically detects available targets to build, and executables to run/debug. We’re inclined to provide this experience for Makefile-based projects as well, however, this requires a lot of heuristics and tuning. In the meantime, you can use existing Makefile plugin to run make targets (note that it doesn’t allow running or debugging executables, you still should use Custom Build Targets for this).

This brought us to the workflow where users work around Makefile projects with the help of File Watchers and the compilation database. The main pain-point is that you have to install the tools to extract the compilation database from your Makefiles. However, the workflow is universal and works smoothly for any project model not supported natively, like build2 or others, as demonstrated by Phil Nash in this video.

Support for Makefile projects: How-to

Modern C++ tooling doesn’t have a single agreed way to handle Makefile projects in an IDE. We’ve identified several approaches (used across other IDEs and editors), which are outlined below:

Option 1: Compiler wrappers

There is a tool called scan-build, which helps you get a compilation database by intercepting compiler calls during the build. The first approach uses a similar concept – the IDE substitutes the actual compiler with wrappers (using CC and CXX environment variables, also through PATH) that would record the compilation command and then call an actual compiler.

The main benefit of such an approach is that it will work not only for Makefile projects, but for any build system. However, this requires a full clean build, which might take too long and might not be possible to do on the machine the IDE runs on.

Option 2: LD_PRELOAD

This approach also takes the idea from the currently existing tooling, which is Bear, and is similar to option 1. In a nutshell, on Unix-like systems, it is possible to set a LD_PRELOAD environment variable and specify a dynamic library that will be loaded before execution of any build process. This will allow intercepting any calls to the compiler.

This approach interferes with the build process less, which is important to some fragile configurations. But it’s Unix-specific (available also on macOS, but requires some special permissions).

Option 3: Parse the output of Make

The Make command prints lots of useful output during its work, which can be collected and reused for getting information about a project. This idea serves as a basis for the third approach. There is also a useful --just-print option, which helps avoid actually building the project during project reload, and so it’s possible to achieve better performance than a regular Make call.

This approach looks nice as it doesn’t affect the build process and allows us to collect the information quicker compared to the full project build. This is also a ‘portable’ option, as the IDE can theoretically start with the Make output recorded on another machine. So while this approach is not extendable to other build systems, it looks to us like the preferred solution from our early days of research.

Support for Makefile projects: CLion’s prototype

As we’ve mentioned above, instead of automating a workaround using a compilation database for Makefile projects by bringing the tools to intercept compiler calls to the user’s environment, we’ve decided to implement the approach of parsing Make’s output. While going this route, we had to deal with many interesting subtasks: distinguishing the compilation command from other shell commands, understanding working directories and their messed up output, and many other things that require some specific heuristics to be implemented. But after all, we’ve nailed it and got a working prototype of the Makefile projects analyzer inside CLion:

What could possibly go wrong?

Here is where it gets really exciting! The internal testing on a huge variety of Makefile projects gave us many hints on how to tune the heuristics. Let’s take a close look at the algorithm details to understand what could possibly go wrong.

CLion runs Make, reads its output, and tries to parse it in order to extract the compilation commands and working directory. Entering/Leaving directory <dir> messages in the output identify the working directory we are currently in. This information is required to understand which source file is actually being built, as file names are often specified relative to the working directory. In some projects these messages are also replaced with cd <directory> && gcc <file>. Accurately extracting this information is a crucial part of the algorithm.

It’s easy to fail here as there are widely used tricks to silence Make. Let’s dive deeper into the Make options! The default behavior for GNU Make is to print directories. Makefile can suppress it by using the .SILENT directive, but invoking Make with --print-directories overrides it. However, Makefile can override that by setting GNUMAKEFLAGS=--no-print-directory, which in turn could be overridden by passing GNUMAKEFLAGS=--print-directory as a command line option when invoking Make.

Inside a directory, the output messages are treated as potential compilation commands. CLion tries to parse them, looking for known compilers and their flags. In the cases where it fails, the line is considered to be just a text string and so is skipped. Interestingly, there are some wrappers like libtool which hide the compilation flags and interfere in the Make’s output, and so makes our current approach fail. Shell and linkage commands interfere as well, but it’s possible to teach the algorithm to skip them accurately.

Projects we used for testing

Let us list some of the projects we used for testing and point to some specifics we’ve found out while parsing the --just-print output. It’s worth mentioning that on most of them the approach that is currently prototyped in CLion does work:

1. Mbed TLS: https://github.com/ARMmbed/mbedtls.
   Comes with .SILENT target which disables printing directories.
2. A guide to basic Makefile projects used in Embedded Development: https://github.com/davepfeiffer/embedded-makefile-flow.
   Doesn’t print directories by default. But overall it’s very generic and simple from the perspective of parsing Make’s output.
3. GNU nano: https://git.savannah.gnu.org/cgit/nano.git.
   The project uses the Autotools, and the output includes many commands for dependency generation.
4. CPython: https://github.com/python/cpython.
   The project uses the Autotools. Several directories aren’t included in the target all (e.g. Modules).
5. OpenJDK: https://github.com/openjdk/jdk.
   This is a huge Autotools project with a customized build process, which hides almost all of the output. For now, our prototype fails on this project. However, we’ve found special make targets that are specifically responsible for IDE support:
   • compile-commands generates a compilation database which you can later open in CLion. (Later, we are planning to write a detailed blog post with instructions based on our internal usage of CLion for OpenJDK.)
   • vscode-project generates a VSCode project.
6. TscanCode static analysis tool: https://github.com/Tencent/TscanCode.
   It doesn’t print the directories, but overall it works fine with our approach.
7. Node.js: https://github.com/nodejs/node
   A huge project with lots of dependencies, which also uses a custom configure script. It’s Makefiles explicitly disable printing directories, but even without it the --just-print is enormously big.
8. Linux: https://github.com/torvalds/linux
   Custom build system (KBuild) is used here and normally it runs in a fairly quiet mode. However, changing to the verbose mode by passing V=1 helps. Still the --just-print output lines contain custom prefixes, and parsing the output produced without --just-print seems to work to some extent, but naturally takes a lot of time.
9. GCC: https://github.com/gcc-mirror/gcc
   Another huge Autotools project. More importantly, it uses a libtool wrapper and so hides some of the actual compilation flags.
10. And there are many others.

Call for help!

Obviously, the variety of Makefile projects is huge and you probably have some interesting projects in mind! We’ll be really happy to take a look and try them out with our prototyped solution. So please do share links to them in the comments.

And if you are ready to play with it on your own Makefile project that’s not generally available, please ping us (here in comments or drop a message to anastasia.kazakova at jetbrains.com) and we’ll share the EAP build and the instructions with you in private, so that you can give it a try and give us your feedback.

Your CLion team
JetBrains
The Drive to Develop

A new CLion 2020.1 EAP build is now available for download!

You can download the build (201.5616.31) from our website, via the Toolbox App or as a snap package (for Ubuntu) and install it side by side with the stable release build.

DOWNLOAD CLION 2020.1 EAP

Let’s take a look at the highlights!

Code completion

Clangd-based code completion has been improved in several ways:

• The rules for showing private and protected methods in code completion have been updated. Now CLion:
  • Doesn’t show private and protected methods for the first completion call, though it does show them for the second one
  • Shows private and protected methods for the first completion call if there are no public methods
• We’ve also fixed an issue with non-existent constructors being suggested when completing type names (CPP-18970).

The formatter and naming

In the naming settings, CLion now has separate settings for struct and class fields:

CLion currently has two formatters – a built-in one and ClangFormat. You can easily switch to ClangFormat if you have a .clang-format config file. And even if you don’t, you can still switch, and CLion will offer to create the config file for you. Now, when you first open a project with a .clang-format config file in the project root, CLion will detect it and switch to ClangFormat for you automatically. Note that in this case CLion enables the Settings/Preferences | Editor | Code Style | Enable ClangFormat option, which is applied either to the individual project (if code style scheme per project is selected) or globally (if code style scheme per IDE is selected).

There are also various performance improvements and fixes for regressions.

Additionally, we recently shared an update on Makefile projects support in CLion. Check out how you can help us test our prototype on a variety of projects or request a private build from us to give it a try on your own!

Check the full release notes here.

DOWNLOAD CLION 2020.1 EAP

Your CLion team
JetBrains
The Drive to Develop

A new CLion 2020.1 EAP build is now available for download!

You can download the build (201.6073.20) from our website, via the Toolbox App or as a snap package (for Ubuntu) and install it side by side with a stable release build.

DOWNLOAD CLION 2020.1 EAP

Let’s take a look at the highlights!

• CLion index now works more accurately with symlinks (CPP-17333).
• A fix for the Cannot run program error happening on CMake target launch from CLion (CPP-19236).
• CUDA support was added earlier in this 2020.1 EAP, and in this build it’s got several improvements:
  • The issue with the alpaka project, when CLion fails to collect compiler info, and so red code is present, was finally fixed.
  • Generate options are now available in CUDA files.
  • A false positive on the OpenCV code was fixed (CPP-18058).
  • CLion now correctly parses the compile_commands.json file generated for CUDA projects (CPP-18926).
• Changing the return type in a trailing return type function no longer breaks the code (CPP-17529).
• Toolchains:
  • Recently we’ve added clang-cl support on Windows. Now CLion takes bitness (x64 vs x86_64) into account, so that the selected clang-cl compiler matches the Visual Studio toolchain selected.
• Formatter:
  • #pragma region and #pragma endregion can be used in CLion for code folding:
    
  • In using and namespace, the equal sign is getting surrounding spaces if configured in settings.
  • CLion now doesn’t apply an incorrect indentation to the lines after the macro definition (CPP-18574).
• We are currently unifying all remote configurations to use the common SSH Configurations UI:
  

This affects all IntelliJ-based IDEs, and CLion is no exception. Wherever a new SSH configuration originated from (be it remote toolchains settings or Remote GDB server configurations), it’s now located in Settings/Preferences | Tools | SSH Configurations.

Besides, check out the update on the Commit tool window & Commit dialog.

Additionally, we recently shared an update on Makefile projects support in CLion. Check out how you can help us test our prototype on a variety of projects, or request a private build from us to give it a try on your own!

Check out the full release notes by the link.

DOWNLOAD CLION 2020.1 EAP

Your CLion team
JetBrains
The Drive to Develop

You’ve probably heard that dogfooding at JetBrains is a mission-critical part of our development process. You may also know that we build our own JetBrains Runtime to provide a runtime environment for running IntelliJ-based products. It’s based on OpenJDK, and so, obviously, it’s a great opportunity for dogfooding in CLion.

Besides, there is a huge community contributing to OpenJDK that often asks about tips & tricks for dealing with the native part of the OpenJDK project in CLion. There are already several tried and tested collections of tips & tricks from the community leads. In this blog post, we’d like to share our own tips & tricks from our own experience of developing OpenJDK in CLion.

• Step 1: Get the source code and the tooling ready
• Step 2: Open project in CLion
• Step 3: Generate Run Configurations and Build Targets
• Step 4: A few debugging tips

Step 1: Get the source code and the tooling ready

You can get the latest OpenJDK sources either from the official mercurial repo (hg clone https://hg.openjdk.java.net/jdk/jdk) or from the GitHub mirror (might be faster). Please carefully read how to prepare the local environment.

Download either the latest version of CLion from our site or check out the recent CLion 2020.1 EAP build (this one offers a better debugging experience on Windows).

Step 2: Open project in CLion

While there is ongoing work to natively support Makefile projects in CLion, for this instruction we’ll be using an OpenJDK compilation database to work with the project in CLion.

1. Read how to create the compilation database for the OpenJDK native code ${source_root}/doc/ide.md.
2. Select the build target. If you want to debug your build, the best option is to do configure --with-debug-level=fastdebug.
3. Run make compile-commands to generate the project for all the source code. You can also run make compile-commands-hotspot to generate the project for HotSpot only.
4. Make sure you now have a compile_commands.json file in the ${source_root}/build/<target>/ directory.
5. For some modules, precompiled headers are used. Because of this we suggest building OpenJDK before generating the project model. To build binaries, just call make.
6. Refer to CLion’s online help on compilation databases to understand what they are and the possible ways you can generate one.
7. On Windows, there are a few issues with the OpenJDK compilation database (some are CLion issues and we plan to address them in the future, some are just because of an incorrect compilation database on the OpenJDK side, but we can try and workaround them in CLion): CPP-19223, CPP-19225, CPP-19224. We have this short java program to fix the issues. There is no need to compile it; just do java <path/to/FixCompileCommands.java> <absolute/path/to/generated/compile_commands.json>. The original file will be saved as compile_commands.json.old.
8. Make sure that you have configured toolchains in CLion. On Windows, configure and set Visual Studio as the default (make it the first in the list):
   
9. Now open the generated compile_commands.json as a project in CLion. It will take approximately 20 seconds to load on an average machine.
10. By default, the project root is set to the directory containing the compilation database file. So change the project root directory to ${source_root}.

Now the project is ready in CLion!

Step 3: Generate Run Configurations and Build Targets

The compilation database itself lacks the data required for building, running, and debugging an application. However, you can set up the workflow by adding custom build targets for your compilation database project and then creating custom Run/Debug configurations for these targets.

Custom build targets for OpenJDK

To configure custom build targets, go to Settings/Preferences | Build, Execution, Deployment | Custom Build Targets:

1. Use the default toolchain on Linux and macOS. On Windows, use the Visual Studio toolchain.
2. Configure the new external tools for the build and clean steps:
   
3. On Linux and macOS: set a name and description, select make as the program, and specify the make arguments that should be used to build your image. In our case, the only argument is the make configuration: CONF=macosx-x86_64-server-fastdebug. Set ${source_root} as the Working Directory:
4. On Windows, Unix build tools are still an essential part of the build process, so we run build and clean via Cygwin (or you can do it via WSL). To do this, set the program field to something like C:\cygwin64\bin\bash and arguments as --login -c "cd /cygdrive/c/${source_root}; make CONF=windows-x86_64-server-fastdebug" for build and --login -c "cd /cygdrive/c/${source_root}; make clean CONF=windows-x86_64-server-fastdebug" for clean:
   

Custom Run/Debug configurations

Go to Run | Edit Configurations and start a new Run and Debug configuration based on the Custom Build Application template.

1. Select the custom target you created earlier as Target.
2. Set Executable to the java binary built as part of an image (in our case it is ${source_root}/build/macosx-x86_64-server-fastdebug/jdk/bin/java)
3. Set Program Arguments.
4. The JDK build system is smart, and incremental compilation is pretty fast. However, if you don’t want to rebuild OpenJDK before each run or debug, you can disable build step in the Before launch section of the run configuration settings:
   

We are almost there!

Step 4: A few debugging tips

We debug with the LLDB debugger. This includes Windows, where CLion comes with the bundled LLDB-based debugger for the Microsoft Visual C++ toolchain.

1. On Linux and macOS, create a custom .lldbinit file in the same directory where the compile_commands.json file was generated.
   • Add pro hand -p true -s false SIGSEGV SIGBUS to this file to suppress signal handling.
   • Don’t forget to explicitly allow LLDB to use the config file from the project directory.
2. Some debugger features are not available (that is, they do not automatically show all local variables for the frame) for the binary built with fastdebug configuration. You still can watch any specific variable manually. If you need to debug the binary without any optimizations, switch to the slowdebug configuration.
3. Set a breakpoint (for example, on a line of the Arguments::init_system_properties function) and click the debug button.
4. CLion should stop on a breakpoint in your code:
   

That’s it! Do you have any questions or feedback? Try it out and tell us what you think in the comments below.

Your CLion team
JetBrains
The Drive to Develop

A new CLion 2020.1 EAP build is now available for download!

You can download the build (201.6251.14) from our website, via the Toolbox App or as a snap package (for Ubuntu) and install it side by side with the stable release build.

DOWNLOAD CLION 2020.1 EAP

• IAR toolchain/compiler support
• The first version of the PlatformIO plugin for CLion
• An update to the Change Signature refactoring

IAR Toolchain

The CLion team is now working hard toward Embedded Development support. And this build has taken another important step – support for the IAR compiler/toolchain. Before, CLion already worked with GCC-based toolchains, Clang, and Microsoft Visual C++ toolchain (Intel compiler also works but with limitations). But the IAR toolchain is different, and so collecting compiler information in CLion previously failed.

CLion now supports the IAR compiler, which means it detects the compiler correctly and collects compiler info. Thus, projects using the IAR toolchain load successfully and work in CLion:

Note that MinGW is required for you to be able to use the IAR compiler. You might also be interested in how to use CMake with IAR Embedded Workbench. Additionally, we recommend you use Ninja as a CMake generator because of the following issue: CPP-19327.

We would also love to thank IAR Systems AB for their support and partner licenses, which helped us develop and test the integration.

PlatformIO plugin for CLion

In collaboration with the PlatformIO team, we’ve recently started some work in CLion to improve integration and help CLion users benefit from this new generation ecosystem for embedded development.

There is now an experimental plugin you can install which allows you to try the following:

• Create a new PlatformIO project from CLion’s New Project wizard:
  
• Have CLion PlatformIO projects generated and have several PlatformIO Run/Debug configurations created automatically (for debug and upload).
• Debug with the PIO Unified Debugger from CLion right on chip.
• Run PlatformIO tests (the configuration should be created manually).
• Upload firmware to the chip from CLion.

Don’t forget to install PlatformIO itself to get the plugin working correctly.

We will continue to work on this plugin, so stay tuned!

Default value in Change Signature refactoring

When calling the Change Signature refactoring (Ctrl+F6 on Windows and Linux, ⌘F6 on macOS), CLion updates all the usages of the function. Previously when adding a new parameter to the function signature, CLion simply added a default type value as an argument to the usages (i.e. 0 for numerical, nullptr for pointers). This helps keep the code compilable, but is not always what you want, as you might need some other value to be used (and so in this case you later have to call the Find Usages and update the arguments manually).

Now, Change Signature refactoring includes the ability to point CLion to a value to be used by adding the required value to the new Default value field in the dialog:

If you keep the field blank, the old behavior is applied and the default value for the type is used.

The same logic applies to the Create Parameter From Usage quick-fix and the Add Parameter to Constructor intention:

Extract Parameter uses either the default type value or the value with which the variable is initialized:

There is also a new ability to split terminal sessions vertically or horizontally so that you can run them side by side. Check out the full release notes here.

DOWNLOAD CLION 2020.1 EAP

Your CLion team
JetBrains
The Drive to Develop