Quantcast
Channel: CLion : A Cross-Platform IDE for C and C++ | The JetBrains Blog
Viewing all 678 articles
Browse latest View live

C++ Annotated: November 2019 – February 2020

$
0
0

Hi,

We’re happy to present our new edition of C++ Annotated, which includes our findings on C++ conferences, language evolution, various tools releases, learning materials, and community announcements. We hope you find this a useful and interesting read.

C++ Annotated

Today:

C++ conferences

Because of the outbreak of COVID-19 and various national and local regulations and limitations for travel and mass events, many conferences have been cancelled, postponed, or moved online. So if you are planning a trip for an event, the best practices include checking regularly for news from your conference (organizers are now updating regularly), paying attention to national regulations if the event involves international travel for you, and reading and following CDC and WHO recommendations.

Catch these upcoming conferences while you can

You can find an up-to-date list of conferences around the world at the official C++ Foundation site. If you are excited to propose an interesting topic or talk, check out the ones with open calls for papers:

  • NDC TechTown – closes April 23.
  • CppCon and Meeting C++ CFP are not yet open.

Learn from these events even if you missed them

In our last edition of C++ Annotated, we listed conferences that were upcoming in November 2019. Given the current circumstances, it’s great to see that they all happened! The full list of past conferences, along with links to their YouTube playlists, can be found at the C++ Foundation site. A few worth mentioning from the Nov-Feb time period include:

  • ACCU Autumn – A first-time Autumn edition happened in Belfast, and it was aligned with the C++ Committee meeting happening at the same place. Thanks to that, the event got several prominent speakers from the Committee, and in general there was a whole set of high-quality talks. Find the playlist on YouTube.
  • Meeting C++ – The recordings of the regular and lightning talks are now available. While there were many really valuable presentations, we’d like to highlight just a few of our personal favorites:
    • C++20: The small things by Timur Doumler. When it comes to a new standard, the community often focuses on the big changes. But C++20 is bringing lots of small goodies, and Timur nicely brings them to our attention. A nice result is that, while it might be hard to start using a big feature in your legacy project (due to its revolutionary aspect), the smaller ones are easier to adopt. That’s why we recommend watching this talk!
    • Can AI replace programmers? by Frances Buontempo. Frances wrote the book on Machine Learning – literally. In this talk, she discusses both the philosophical and technical sides of the issues of today and of the future. Does Betteridge’s Law of Headlines apply to the title? The only way to find out is to watch the talk.
  • code::dive has also published the recordings from the 2019 event.
  • The playlist from the CoreHard Autumn 2019 event is available on YouTube.

C++20 Is Done! Prague trip report by Phil Nash

Instead of a regular “Proposals you don’t want to miss” section, this time we’ll discuss the recent C++ Committee meeting in Prague and its outcome. Phil Nash was there, and he’s ready to share a few highlights.

The important focus of the Prague meeting was finalizing C++20. At this stage, that mostly meant processing the last NB (National Body) comments so the draft could be sent off for ISO processing, after which it becomes an official C++ standard! There were a few additional bug reports, some of which surfaced during the meeting, but we (the committee) got through them all (or at least there was nothing left outstanding that could hold up the release)!

The bulk of that work was in the wording groups (Core and Library). The evolution groups were only tied up with C++20 about 20% of the time. Many of the study groups, including the two incubators, also met. So a substantial part of the week was actually devoted to C++23 and beyond!

C++20

From an end-user perspective, the tweaks to the C++20 draft were fairly minor – mostly just fixing issues that make the standard more consistent and, hopefully, adding less accidental complexity. A few small features were taken out as issues were identified that we didn’t have time or confidence to fix in a single meeting. In some cases, we actually fixed things. For example, aggregate initialization of std::arrays in the presence of CTAD introduced a few regressions which have now been fixed.

C++23++

Most of the more interesting, larger proposals come with caveats that they may not make it into C++23, or even C++26 in some cases! There are two, in particular, that most of us are hoping will make it into C++23 (but it’s most important that these are done right, even if that means waiting longer):

Pattern Matching

If you’re not familiar with pattern matching from other languages, in a nutshell you can think of it as extending switch statements to work with complex runtime, or even dynamic, values – that’s the matching part – but it also extends structured bindings with even more powerful destructuring capabilities. This combination makes pattern matching one of the most versatile and expressive features that is missing from the language today.

Even if you are familiar with the feature in general, this is definitely one of those features that is necessarily far more complex in C++ than in most other languages because of its rich variety of value categories. The challenge of this proposal is to leak as little of that complexity as possible without restricting how the feature can interact with the full language.

The syntax is still very much in flux, but here’s an example from r2 of the proposal, which matches on a std::variant:

inspect (v) {
  <int> i: strm << "got int: " << i;
  <float> f: strm << "got float: " << f;
}

In this meeting, we spent most of the time discussing whether match expressions should be required to be exhaustive, and whether there should be a difference between the statement and expression forms.

Reflection

Reflection is an umbrella term for introspection and generation. Many languages have runtime reflection, which can be very powerful but comes at the cost of performance (and executable image size). The proposals for C++ are for compile-time reflection (which can support runtime introspection, too). This promises to be one of the biggest additions to C++ since its very beginning!

In recent meetings, the discussion had been focused on migrating type-based syntax from the earlier proposals to take advantage of the advances in constexpr to make everything look much more like normal code. For example, holding lists of members in a constexpr std::vector.

In the previous meeting in Belfast, and continuing in Prague, a change of direction was considered! The Circle project (a C++ compiler extended with simple, yet rich, metaprogramming facilities) has been in the spotlight, and the discussion has been about whether Circle’s approach is better (at least for generation) and whether we can take any cues from it.

The sentiment from the Prague discussion seemed to be that there are some thorny issues with Circle’s approach when it comes to cross-platform or embedded development, and this is probably not the direction we will take in the committee. However it was also recognized that, in some ways, Circle offers a drastically simpler usage – and maybe we could investigate more in that direction from where we are.

C++20 Is Done!

C++ Committee 2020
The “Official” C++20 photo

For more details, see Bryce Adelstein Lelbach’s exhaustive, as always, report on Reddit. See also the video that he did with Conner Hoekstra.

Interviews, tools & techniques, language learning pieces, and thoughts

In-class member initialization

member init
In a recent blog post, Bartlomiej Filipek discussed how in-class member initialization has changed from C++11 to C++20. This basic overview is still worth reading as a refresher on all the changes that have been made through the standards. Bartek gives an overview of non-static data member initialization, bringing samples with side effects to the table. He also discusses copy and move constructors, highlighting how it works with aggregates (including some bug-fixes between C++11 and C++14) and bit fields. He adds a few words about inline variables, which allow for easier development of header-only libraries, as there’s no need to create cpp files for static variables or use hacks to keep them in a header file.

Finally, his blog includes more educational articles like that, so we recommend you follow and read it through from time to time.

C++20 Reference card

2017cardsThis one also comes from Bartek, who put together all the core elements of the newest standard and built them into a reference card. He did a similar thing for C++17, so if you sign in and subscribe to the mailing list, you’ll get both. C++20 is packed with some very notable features for you to remember, including concepts, modules, coroutines, ranges, the spaceship operator, constexpr/consteval/constinit, designated Initializers, std::format, std::span, a Chrono update, and much more. The card won’t teach you about these features in detail, but it will give you a general overview of the most notable and useful changes.

On Requires expressions

Requires expressions
In his blog, Andrzej Krzemienski has posted about a C++20 Concepts feature called requires-expression. He actually departs from the Concepts feature and evaluates requires-expressions on their own. One interesting usage he mentions is testing whether a class has a full interface implemented. This works because when a requires-expression is used outside of any template, a compilation error is generated when the requirement is not satisfied. The blog post shows how you can use requires-expressions to evaluate arbitrary predicates on types or to test whether any member functions exist, the constraints on their return type, and whether the function declared not to throw exceptions. At the end of his post, Andrzej discusses some interesting peculiarities about testing the validity of expressions in contrast to predicates.

Sourcetrail is free and open-source

sourcetrailIn November, Eberhard Gräther announced that Sourcetrail is now free and open-source. Started as a Coati project, Sourcetrail is a source-code explorer for code written in C, C++, Java, and Python, which brings users an interactive combination of graph visualization and code display. Eberhard has presented both the approach in general and this particular tool to the public at several conferences, and it has definitely earned some love from the community. The source code is now available on GitHub, and you can support its authors via Patreon.

Drop-Dead-Simple

DDS
The author of the well-known CMake Tools Extension for Visual Studio Code has presented DDS – the Drop-Dead-Simple build and library management tool with a special focus on C and C++ libraries. It’s based on libman project concepts (a new level of indirection between package management and build systems), and it insists on a Toolchain as a major requirement (being itself completely independent of platforms and compilers). The main goal is to help people maintain and spread libraries easily. A detailed description of the reasoning behind this tool, the approach taken to building it, and some practical samples can be found in the blog post.

What is Modern CMake?

modern_cmakeIn his blog post, Kuba Sejdak states that linking with libraries in Modern CMake behaves very much like inheritance. The reason for this is that the linked target is passing all its PUBLIC and INTERFACE properties to the library it links with. The author provides two useful examples – hiding “private” headers from libraries in the linkage process and defining header-only libraries. Check them out to see how the new CMake “inheritance” can be used.

Move, simply, at Sutter’s Mill

Herb Sutter wrote a useful FAQ on Move, one of the trickiest and most widely misunderstood language features. The questions are interesting in their own right, but the answers are super useful, too. Herb discusses the state of an object after it has moved, whether it’s always changed or whether it can be documented, whether objects are somehow usable after being moved from, and much more. This is definitely a must-read for sorting out all the specifics of Move and for learning a few tricks.

Releases

  • Visual Studio Online – Microsoft has unveiled the Visual Studio Online Public Preview. It brings Visual Studio Code, Visual Studio IDE, or the included browser-based editor to you for collaborative development, and it’s useful for prototyping features and reviews and for educational purposes. The environments work as the foundation and are Azure-hosted. Stay up to date with updates from the team about the recent changes.
  • Qt Visual Studio Tools – They are coming to Linux with Visual Studio’s Linux projects support later this summer. The plan is to support Qt targets in the VS Linux development workload. A proof-of-concept sample shows a Qt project debugged both locally on Windows and remotely via gdbserver on Linux.
  • CLion 2019.3 – The JetBrains IDE gets completion implemented on top of Clang, the long-awaited Ninja and other CMake generators, WSL2, built-in code coverage, and C++20 Concepts support. The CLion 2020.1 EAP is now available introducing CUDA support, clang-cl on Windows, and the IAR compiler for embedded development.
  • ReSharper 2019.3 – ReSharper comes with wider C++20 support (such as C++20 Concepts support, like in CLion), new type hints, and the sorting #includes formatter option. For game developers, it includes more profound Unreal Engine support. The 2020.1 EAP is also up and running with even more for C++20 and UE4.

The JetBrains C++ team
The Drive to Develop


CLion 2019.3.5 bug-fix update

$
0
0

A new bug-fix update, CLion 2019.3.5, is now available for download! You can get build 193.6911.21 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:

  • The IDE UI freeze while debugging has been fixed (CPP-18278).
  • Formatter improvements:
    • Fixed the incorrect formatting of the macros used inside the macro argument (CPP-18644).
    • Fixed the incorrect formatting of the strings concatenation used inside macro calls (CPP-18628).
  • VCS: commit actions are no longer disabled on a commit of a deleted file (IDEA-225882).
  • More fixes from the IntelliJ Platform.

Full release notes are available here.

Additionally, the CLion 2020.1 EAP is now up and running. It brings CUDA enhancements, support for Clang-cl and IAR compilers, the ability to debug customer targets, Data Flow Analysis rewritten on Clang, a PlatformIO plugin, and more. For more details please see this page.

Your CLion team
JetBrains
The Drive to Develop

CLion 2020.1 EAP: Macros and Variables in Configurations, Input Redirection, and More

$
0
0

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

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

DOWNLOAD CLION 2020.1 EAP

Support for macros and path variables in Run/Debug configurations

Sometimes, instead of running your program directly, you may want to pass it as an argument to another program started from CLion (when using an emulator, for example). Or you might want to use a project-related path in the Program Arguments or Working Directory fields in the Run/Debug Configurations. Now you can do that!

Macros and path variables can currently be used in the following configuration types:

  • CMake Application
  • Custom Build Application
  • Gradle Native Application

Further work is still required for unit testing, the Remote GDB Server, and some other configuration types.

Editor macros give you access to values like:

  • The build directory for the current CMake run configuration.
  • The generation directory for the current CMake run configuration.
  • The project file directory.
  • And many others.

Edit Macros

Alternatively, you can use Path Variables, which you can configure in Settings/Preferences | Appearance & Behavior | Path Variables. The typical use case is creating a Path Variable for a library that is used widely in your projects but is located outside the project directory (check our webhelp article to learn how to configure it).

Path variables and editor macros can be used in the Program Arguments or Working Directory fields in the Run/Debug Configurations. For macros, click the plus sign to open the full list:
Prompt arguments

Input redirection

Sometimes you want to redirect input from a file to stdin of your application. This is now possible! In the Run/Debug Configuration, you’ll find a new field called Redirect input from. Enable it, and fill in the file path/name:

Input redirection

A few things worth mentioning here:

  • The macros and path variables mentioned above work here as well.
  • Relative paths are prepended with the Working directory path.
  • Absolute paths, in the case of remote configurations, will be mapped to the remote paths according to the path mappings configured in the Deployment settings.

Tip: If you want CLion to ask you to choose a file input every time you run the application, use the FilePrompt macro here, which invokes a file selection dialog on every application launch:
Prompt redirection

A few known issues:

  • Input redirection does not yet work when debugging with GDB using the Cygwin toolchain.
  • Input redirection currently works only with the CMake Application, Custom Build Application, and Gradle Native Application Run/Debug configurations.

Clangd-only completion

In 2019.3, we introduced Clangd-based code completion in CLion. Clangd, as one of the completion providers, helps deliver faster completion results. However, the rules for mixing Clangd with CLion’s own completion provider are quite complicated. Sometimes they even cause issues with the prioritization and ordering of results. After a few rounds of tests and measurements, we’ve decided to turn on a new mode in which completion is fully provided by Clangd. Of course, if a crash or some other serious issue occurs, CLion will silently switch to other providers to be sure that completion is still operating. CLion also uses its own completion to provide symbols from non-included files if Clangd-based completion fails to find anything.

This behavior is controlled by the Code Completion setting in Settings/Preferences | Languages & Frameworks | C/C++ | Clangd. At the moment, Only Clangd completion is set as the default value.

Additionally, to make Clang-based code completion (and thus CLion completion) more stable and accurate, this build comes with the following improvements:

  • Fixes to several Clangd crashes.
  • Completion for using namespace should suggest only namespaces (CPP-19175) and a space should be inserted (CPP-11766).
  • Frameworks are no longer duplicated in the completion list (CPP-19127).
  • Completion now suggests keywords class and struct for enum (CPP-18957).
  • Completion now inserts angle brackets for template functions and classes that require it (like for example, std::numeric_limits, boost::lexical_cast, std::make_shared, std::make_unique, and others):
    Completion for angle brackets

Other improvements

Data Flow Analysis (DFA) was recently moved to Clangd, and now we’ve given it a few fixes and improvements, including:

  • More accurate Local variable not used inspection on structured bindings (CPP-12900, CPP-13006).
  • Fixes for the incorrect Unreachable code errors (CPP-19185).

For toolchains:

  • CMake 3.16.5 is now bundled.
  • Fixes for CMake not working in many cases when user paths contain non-ascii characters.

And there are, of course, many others. You can find the full release notes here.

DOWNLOAD CLION 2020.1 EAP

Your CLion team
JetBrains
The Drive to Develop

CLion 2020.1 Reaches Beta

$
0
0

CLion 2020.1 goes Beta! To install build 201.6668.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 2020.1 BETA

Find the main highlights below.

Code completion

In the previous EAP build, completion that’s based only on Clangd became the default. This behavior is controlled by the Code Completion setting in Settings/Preferences | Languages & Frameworks | C/C++ | Clangd.

To improve your user experience with completion, we’re introducing a few fixes in this Beta:

  • Completion suggestions in the context of a template parameter list are now more accurate (the typedef keyword is no longer on top, CPP-19085).
  • Completion in type aliases is more accurate as well (thanks to removing constructors from the using context, CPP-19171).
  • CLion can now complete folders that are symlinks.
  • Completion for int has been improved (CPP-19520).

Other fixes

  • For compilation database projects, when CLion collects compiler information it now filters out some flags that do not affect the information requested. -MD and -MMD flags are good examples as they generate dependency files and might clutter the project directories with unnecessary compiler-file*.d.
  • For Python, the notification ‘Configure Python interpreter’ will now open a settings window (CPP-19536).

More fixes from the IntelliJ Platform have also made their way into this Beta. The full release notes are available here.

Your CLion team
JetBrains
The Drive to Develop

CLion 2020.1 Release Candidate is Here

$
0
0

Please welcome the Release Candidate for the upcoming CLion 2020.1!

To install CLion 2020.1 RC (build 201.6668.86), download it from the website, update from our Toolbox App, or use a snap package (for Ubuntu). Please note that to use CLion 2020.1 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 to update the latest 2019.3 build to the 2020.1 release version.

DOWNLOAD CLION 2020.1 RC

The main highlights:

  • The Clangd-based engine received the following improvements:
    • A fix for the Clangd crash in the name hints.
    • Incorrect completion in multi-cursor mode is fixed (CPP-19680).
    • Concepts are working again in CLion with the Microsoft Visual C++ toolchain, after recently being broken.
  • CLion no longer fails if the Clang-cl compiler bitness doesn’t correspond to the toolchain bitness. Instead, the IDE passes the correct flags to build the proper binaries.
  • Unit testing improvements:
    • CLion’s automatic arguments for Boost.Test are no longer in conflict with the user’s arguments (CPP-17734).
    • The Google Test built-in test runner no longer incorrectly reports a certain failing test as succeeding (CPP-14927).
    • Google Test targets for v1.8.1+ are now correctly recognized by CLion as Google Test targets, and corresponding Run/Debug configurations are created automatically.

Follow the link to check out the full release notes.

We are now busy putting the final touches on the release, so please report any problems you encounter to our issue tracker. This way, we can sort them out before the final release (though, depending on their priority, the actual fixes might be postponed for later 2020.1.x bug-fix updates).

Your CLion team
JetBrains
The Drive to Develop

Live Webinar: CLion Ask Me Anything session

$
0
0

Do you have a question you’re dying to ask the CLion team? Are you curious about how to set up remote mode, trying to get started with Arduino, or wondering what breakpoint types are possible in CLion? Or maybe you are interested in our plans regarding Makefiles. Then the Ask Me Anything (AMA) session with the CLion team is just the event for you!

CLion_ama

Developers from the CLion team will join to cover the following areas of expertise:

  • C/C++ languages support, adoption of new C++ standards in CLion, Clangd-based language engine, code assistance.
  • Project models (CMake, compilation database, and future Makefile support).
  • Debugger integration.
  • The formatter (CLion’s formatter and ClangFormat integration).
  • Unit testing (covering Google Test, Boost.Test, and Catch).
  • Embedded development.
  • Remote development.

Join us on Thursday, May 7, 5pm CEST | 4pm GMT | 8am PDT.

Register now!

Your CLion team
JetBrains
The Drive to Develop

CLion 2020.1: Dozens of Improvements Across the IDE, and Benefits for CUDA and Embedded Projects

$
0
0

Let’s start with a big wish for everyone to stay safe! While it’s obviously sometimes hard to focus on your work these days, as there are other important things happening, we’ve tried our best to keep doing what we are good at – creating great tools for developers to increase their productivity. So we are here to introduce a fresh CLion 2020.1 release!

CLion 2020.1 release

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.3 (2019.3.5).

DOWNLOAD CLION 2020.1

Here is a quick overview of the main highlights. If you are interested in the specific details, please read on:

CUDA projects

CUDA C and C++ are essentially C/C++ with a few extensions, and CLion 2020.1 is now able to handle CUDA code correctly. Most of our effort was put into teaching CLion’s language engine to parse such code correctly, eliminating red code and false positives in code analysis. The enhanced support also includes code navigation, code documentation, and other code assistance actions that work within CUDA code. And finally, code completion was expanded to complete angle brackets for kernel calls:
CUDA completion

(For the test, we used the ClaraGenomicsAnalysis project from GitHub.)

Additionally, CLion now supports CUDA file extensions – .cu/.cuh. You can select them when creating new C/C++ files. By the way, did you know that CLion suggests CMake targets to add your newly created files to? Now CUDA targets (created with cuda_add_executable / cuda_add_library) are added to the list of possible options to select from:
CUDA new file

Finally, you can start a new CUDA project in CLion – the New Project wizard helps you generate the sample CMake and main.cu files. Learn more about how to work with CUDA projects in CLion in our webhelp.

Embedded development

We keep improving CLion for embedded development, and in this release we’ve taken two important steps forward. The first is IAR compiler support. CLion can now collect compiler information correctly, making it possible for you to successfully use the compiler in your embedded projects. Here are a couple of useful tips to get you started with the IAR compiler:

  • MinGW is required. Use the MinGW environment in the IAR toolchain settings in CLion and provide paths to the IAR compiler in the corresponding fields.
  • Check out these notes on how to use CMake with IAR Embedded Workbench.

IAR compiler
We’d like here to once again thank IAR Systems AB for their support and partner licenses. And we’d also like to assure our readers that we’ll continue the collaboration. Our next goal is to further investigate integration with this toolchain.

Our second big step forward is the ’PlatformIO for CLion’ plugin. PlatformIO is a new generation ecosystem, and it can be super useful for getting started quickly with an embedded development project (for example, for Arduino). The plugin generates a PlatformIO CMake-based project when the corresponding project type is selected in the New Project wizard, calling a proper PlatformIO command for you in the background:
PlatformIO plugin
For such projects, CLion automatically creates configurations for debug and upload. You can also create a PlatformIO Debug configuration to use the PIO Unified Debugger. Read on for more details in the official documentation.

Windows projects

We’ve seen a growing number of developers on Windows using CLion. Actually, Windows is a primary platform for our users, according to our statistics. That is why we have focused on a few of the most popular requests from the Windows community.

Clang is the second most popular compiler after GCC (according to The State of Developer Ecosystem 2019 study). Microsoft Visual Studio Compiler is of course the leader on Windows, but Clang-cl is also widely used. You can install it from the LLVM website or along with the Visual Studio tools. And it’s now possible to use it within CLion!
Clang-cl support

Another good piece of news for Windows developers is that the LLDB-based debugger developed by JetBrains for the Visual Studio C++ toolchain is now the default debugger for this toolchain. So you can start using it right away! In the screenshot above, you can see it’s preselected for the Visual Studio toolchain. Please note that this debugger is not a regular LLDB build. Rather, it is developed by the JetBrains team and can handle Native Visualizers (to enable Native Visualizer support, go to Settings | Build, Execution, Deployment | Debugger Data Views | Enable NatVis renderers for LLDB).

Check out this short demo:

Clang-based tools update

In another important development, our team is moving to our Clangd-based language engine wherever possible. There are two main reasons behind this move. First, we want to develop more accurate language features to catch up quickly with the recent updates to the language standard. Second, we want to improve the performance of language agnostic actions (which is not always possible with Clang, but we continue to experiment with more features).

In CLion 2020.1 we’ve moved Dataflow Analysis fully to Clangd. What is DFA, and why is it useful? DFA checks analyze how data flows through your code and detect potential issues based on that analysis. For example, they identify conditions that are always false or always true, endless loops, missing return statements, infinite recursion, and more:
DFA
Most compilers don’t do that for you. For sure, DFA requires very accurate code parsing and resolve, and it can take a significant amount of time, especially when the underlying resolve is slow. So moving to Clangd is a step toward improving the performance of such analysis checks.

In previous versions of CLion, we introduced a Clangd-based completion provider. But at that time it worked in combination with CLion’s own providers. During the 2020.1 iteration, we polished the completion provided by Clang (by fixing dozens of related issues and adding missing completion features) and finally enabled the mode in which Clang is the only provider for code completion in CLion as the default. This resolves some prioritization and ordering issues.

ClangFormat and Clang-Tidy are standard tools for many C++ projects, and their config files are often committed to project repositories. CLion’s integration for these tools, however, was not switching to them automatically. We sincerely thank our users who pointed out this inconvenience! CLion now:

  1. Detects the .clang-format config file in the project root and switches to ClangFormat for you automatically (note that the IDE switches to per project settings at this moment).
  2. Detects the .clang-tidy config file and automatically turns off the use of the IDE settings for Clang-Tidy in favor of this config file.

We do hope this makes working with these two Clang tools much nicer for you!

Check out this short demo:

Refactorings, formatter, documentation, and editor enhancements

With CLion you receive many useful refactorings, and one of the most popular is Change Signature (Ctrl+F6 on Windows and Linux, ⌘F6 on macOS). It allows you to change the function name and return type, as well as add, remove, and reorder parameters. And the biggest value (in comparison to manually updating the function) is that when changing a function signature, CLion searches for all usages of the function and updates all the calls, implementations, and override replacements of it that can be safely modified to reflect the change.

Here you might ask: What happens to a function usage when a new parameter is added? Previously, CLion added the default type value to the usages as an argument (i.e. 0 for numerical, nullptr for pointers) in order to keep your code compilable. With CLion 2020.1, you can tell CLion right in the refactoring dialog which value to substitute across all updated function usages:
Change Signature

Note the code completion available in 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 formatter has been updated in this release, with new separate naming settings for struct member fields and class member fields. And code foldings now work for #pragma region and #pragma endregion.

Other editor updates include:

  • Quick Documentation – a universal tool to preview documentation and get information about function signature, inferred types, and macro replacement – is now available on mouseover.
  • The default font in the editor has been changed to JetBrains Mono, a new open source font created by JetBrains.
  • A new default light theme – IntelliJ Light – is now the standard theme across all the different operating systems.
  • And if you need several terminal sessions to work with at once, you can now split your terminal vertically or horizontally so that you can run multiple sessions side by side:
    Terminal split

Check out this short demo:

Run/Debug configurations

Run/Debug configurations help you launch applications for running and debugging them from within CLion. In this release, they’ve received several important updates:

  • The Remote GDB Server and Embedded GDB Server configurations now work with custom targets. This allows you to debug your application on a remote host or on the microcontroller from the CLion instance running on your local machine, not only in CMake-based projects but in any custom applications (including compilation database).
  • Google Test targets for v1.8.1 and higher are now recognized correctly in CLion, and corresponding Run/Debug configurations are created automatically (making it possible to run tests in CLion’s built-in test runner).

CLion 2020.1 brings macros and path variables to Run/Debug configurations:

  • Macros are predefined, and you can look through the list of available macros in the dialog that opens when you click on a plus sign in the Run/Debug configurations dialog. Note that macros are only available for CMake, Custom Build, and Gradle Native Applications at the moment.
  • Path Variables can be configured in Settings/Preferences | Appearance & Behavior | Path Variables. The typical use case is to create a Path Variable for a library that is used widely in your projects but that is located outside the project directory.

The Prompt/FilePrompt macro is especially useful when combined with the new Redirect input from field in the configuration. This field helps you redirect input from a file to the stdin of your application, and the FilePrompt macro invokes a file selection dialog every time the application launches:
Redirect input

Check out this short demo:

IntelliJ Platform updates

As usual, VCS and other IntelliJ Platform improvements are coming to CLion, in addition to an update for the IntelliJ Rust plugin. More info on the latter will be published separately very soon, so stay tuned!

What’s going on with Makefile support?

Whoa whoa whoa! Who said anything about working on Makefile support in CLion?! Well, whoever they were, they were correct. We’ve built a prototype of the Makefile project analyzer inside CLion and did a blog post on the approach we took and the state of the current solution. And with the help of our faithful users, we’ve built a list of projects for testing this prototype.

There are approximately 40 projects on the list at the moment, and more than half of them have been checked (CPython, some embedded projects, Nano, Nodejs, PostgreSQL). For the most part, they worked fine. Still, there are some projects on which the prototype failed (for example, because of wrappers like libtool). You can find GCC, FreeBSD, Wine, and Perl among these unsuccessful projects. There are also some brave users who tested the prototype on their private projects and gave us some really valuable feedback! Thank you all for that.

So the work continues. We plan to make the prototype public in the 2020.2 EAP. In the meantime, if you are willing to help with this endeavor, check out this call.

That’s finally it! Please give CLion 2020.1 a try. Update today if you have an active subscription, or start your free 30-day trial to evaluate the new features!

DOWNLOAD CLION 2020.1

Your CLion team
JetBrains
The Drive to Develop

CLion Turns 5!

$
0
0

How it all began

This story starts in AppCode. Back in 2011, Max Shafirov, the current JetBrains CEO, announced the first steps toward C++ support in AppCode, our IDE for iOS/macOS development:
AppCode Cpp support

The work started out simply, just dealing with macros when covering Objective-C++ code. But before long it turned into full-featured C++ support, including STL and libc++ understanding, correct parsing for the template specialization, and getting into C++11 and later standards specifics.

This was later followed by an April Fools’ Day announcement, which made us realize there was great demand for a C++ IDE. After that, we did some extensive research to better understand the market. (Luckily, nowadays we have our yearly The State of Developer Ecosystem research bringing significantly more data to us on a regular basis.)

A couple months after the first release of both CLion and ReSharper C++ in April 2015, we published the whole story in this longread in our company blog.

CLion 1.0 banner

This week, we turned 5! And we celebrated yesterday in the best way we could – with the 2020.1 release 😉 When we started CLion, it was a very ambitious idea, and it still is. But we are more confident than ever that we can accomplish the mission!

The team behind the product

Creating a truly helpful tool takes being an integral part of the community, feeling and sharing its needs, pains, and frustrations. We have C++ developers in the team with various backgrounds, as well as some who never did C++ professionally. But we are grateful to the C++ community that helps us fill the gaps. It’s impossible to name here each individual who supports us, as there are so incredibly many of you! But we do want to thank you all!

The CLion team now has 26 members! Including:
18 developers
3 QA engineers
2 support engineers
1 technical writer
1 developer advocate
And me, the product marketing manager.
CLion team

But there are also many other people in JetBrains who contribute to our success. And we are happy to be in such a great company!

Today and Tomorrow

The C++ language is a challenge for any IDE. Over the years, we’ve not only discovered many tricky cases, but we’ve also started talking with the community about the C++ tooling challenges, and hopefully this has helped the C++ Committee notice the issue. We are grateful to the people there who are open to the discussions! We also gladly provide free licenses to the C++ Committee so that we can learn their feedback. They are on the cutting edge of the language, and we are eager to know if we are aligned.

Speaking of free access programs, we see thousands of students using CLion daily to take their first steps in the amazing world of software development. And we are excited to find that CLion is used widely among ICPC teams (our statistics for this come from the 2019 ICPC World Finals, which happens on Linux and where only C++, Java, Kotlin and Python can be used).
ICPC tools

We work on Remote and Embedded development support, and we’ve detected an increase in customers from the automotive industry, especially those creating self-driving experiences. (Our customers and friends from BMW definitely made us smile with their autonomous driving commercial!)

We are certainly thankful to Google for their firm belief in us. With the very first release of CLion, its C++ support was adopted by Android Studio. Our collaboration with the Google team has been, and continues to be, very productive and beneficial to CLion.

We know we have busy and interesting times ahead of us, with lots of critical debts to be addressed, many important fixes to implement, and lots of extra value to add to the product. We also know that you might sometimes feel disappointed with things we’ve missed or haven’t managed to fit into the product. We’d like you to know that these things bother us as well! JetBrains is not about KPIs or management hierarchies. It’s about how we feel about our tools, how we as a team listen to the community needs, and how we cope with your requests. And we know we can do better in many respects. So we’ll try our best to work through critical areas and improve!

Birthday story

Finally, since it’s a birthday celebration, we have a present to share with all of you. A story! Phil Nash is happy to read a book for you. Find a comfortable seat and enjoy these first chapters of CLion’s life:

We always pass all the feedback from various channels to the team’s chat, be it good or bad. So if you want to say something to us, please do so in the comments. Thank you all and stay tuned! 😉

Your CLion team
JetBrains
The Drive to Develop


CLion 2020.1.1 Bug-fix Update

$
0
0

Today we’re making available the first bug-fix for the recently released CLion 2020.1. CLion 2020.1.1 (build 201.7223.86) 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

Here are the main highlights:

  • Toolchains:
    • CLion 2020.1 introduced CUDA support. This update fixes the issue where CLion was not able to pick the non-default host compiler for CUDA.
      There are two different ways of specifying the host-compiler that NVCC should use during compilation.
      • For older CUDA projects using find_package(CUDA), the important CMake variables are CUDA_HOST_COMPILER and CUDA_NVCC_FLAGS.
      • For newer projects that specify CUDA explicitly as a language, CMake uses the variables CMAKE_CUDA_HOST_COMPILER and CMAKE_CUDA_FLAGS instead.

      For details check here.

    • The compiler is now detected correctly for Cygwin (CPP-19908).
    • CLion 2020.1.1 recognizes WSL Ubuntu20.04 distribution.
  • In Qt code: QStringLiteral and QByteArrayLiteral are now highlighted correctly (CPP-19916).
  • Clang tools:
    • A fix for a Clangd crash on C++20 code.
    • A fix for the Reformat Code action that caused an IDE freeze when ClangFormat was in use.
  • Code completion:
    • Completion was skipping parenthesis when Tab indentation was used (CPP-19902).
    • An issue with header name autocompletion has been fixed (CPP-19675).
    • A few issues with incorrect (CPP-10037) or redundant (CPP-19310) symbols completed were fixed.

The full release notes are available here. If you haven’t yet updated your CLion to 2020.1, now is a great time to do so!

DOWNLOAD CLION

Your CLion Team
JetBrains
The Drive to Develop

What’s Next: A Roadmap for CLion 2020.2

$
0
0

CLion 2020.1 has landed and has been followed up with its first bug-fix update, so it’s time to talk about our plans for the next release.

Special thanks

We have a good tradition to celebrate successful releases by giving our most sincere thanks to our Early Access Program users. Today we’d like to extend our special thanks to these fine folks who’ve been most active, along with a complimentary 1-year CLion subscription:

  • Mansur Mustaquim
  • Taw Moto
  • Pavel Samolisov
  • Tom Evers

We’ll email you in the next few days with a code for getting a new subscription or extending your current one. If you’d like to pass the code to a friend or colleague, that’s OK, too!

Roadmap: CLion 2020.2

Our main priorities for 2020 remain unchanged. Let’s see what particular enhancements we plan to implement during the next release cycle.

Please note: The following is only a preliminary plan. We cannot guarantee that all of the features listed below will be included in CLion 2020.2.
  • Language support and Clangd
    • Improve the stability of the Clangd-based language engine, investigate and fix memory leaks, and improve memory consumptions in general.
    • Enable Clangd-based code completion before indexing is complete.
    • Use Clangd-based engine for CLion’s Simplify inspection.
    • Continue fixing particular freezes in various areas.
    • Work on reducing CPU usage on projects like Eigen and others.
  • Project models
    • Continue with the Makefiles prototype (we hope to open it for public testing during this release cycle).
    • Support new features from CMake 3.16 and 3.17.
    • Allow disabling CMake profiles (CPP-12870).
  • Embedded
  • Debugger
    • Further improvements to the LLDB-based debugger on Windows for the Microsoft Visual C++ toolchain.
    • Ability to debug as root (CPP-7224).
    • Ability to debug with a core file (CPP-7977).
  • Unit testing
    • Update Boost.Test & Catch2 integration to support the latest enhancements in these frameworks.
  • Continue with various fixes in other subsystems, including Remote, Formatter, Code Coverage, Profiling, and more.

That’s it! If you have any new feature requests, please send them to our tracker. We’re listening!

Your CLion Team
JetBrains
The Drive to Develop

CLion 2019.3.6 Bug-fix Update

$
0
0

As you probably know, we released CLion 2020.1 this April and since then we’ve published our plans for CLion 2020.2. For those using the previous version, v2019.3, today we’d like to provide a helpful bug-fix.

CLion 2019.3.6 (build 193.7288.25) is now available for download 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:

  • C++ specific fixes:
    • A fix in Clangd which led to a crash on catch.hpp file (CPP-18783).
    • Concepts support, introduced in v2019.3, now also works with the Microsoft Visual C++ toolchain (CPP-19696).
  • From the IntelliJ Platform:
    • We’ve fixed the regression that prevented the IDE from starting if it was installed in a path with non-ASCII characters (IDEA-235754).
    • The IDE now shows the confirmation dialog when deleting a directory that is under SVN (IDEA-228828).
    • A bug is fixed with the licence server address cleared when it’s unreachable (IDEA-235344).
    • Other IntelliJ Platform fixes.
  • The issue with displaying the context menu or main menu popups in Full Screen mode under XFCE has been fixed (JBR-2143)
  • Plus a few other JetBrains Runtime fixes.

Your CLion team
JetBrains
The Drive to Develop

Webinar Recording: CLion Ask Me Anything Session

$
0
0

On May 7, we ran an exciting CLion Ask Me Anything session. 2 hours, 9 speakers, 7 demos, and 140+ questions – this was really inspiring and motivating for the team and hopefully useful for all attendees. The most frequent comment afterwards from the team members was, “Let’s do this again!”. We’d also like to say huge thanks for all your compliments and good wishes in the questions pane!

The recording of the webinar is now available on the JetBrainsTV YouTube channel. And here are some useful timestamps so you can instantly jump to any section:

  • C++ language support
    • 02:29 – The evolution of the language engines in CLion.
    • 05:16 – Handling preprocessor code.
    • 09:00 – Plans for Qt support.
    • 15:30 – Code analysis tools in CLion, how to add support for more, and if/when CLion will support the C++ Code Guidelines rules.
    • 18:57 – What are the plans for C++20 support?
    • 19:55 – Does the CLion team participate in the C++ Committee Meetings and what are your goals there?
  • 22:04 – CLion performance tips
  • Project model support
    • 27:08 – Makefiles prototype demo.
    • 34:36 – Other project models (Meson, Bazel). What are the plans? How to workaround via the compilation database?
  • Debugger
    • 42:24 – Debugger Tips & Tricks demo.
    • 52:13 – How to limit the debugger to “just my code”?
    • 56:22 – CLion plans for CUDA debugger, reverse debugging, and cross-language debug.
  • Remote development with CLion
    • 01:02:01 – Remote development with CLion – short demo.
    • 01:10:48 – Setting a project inside Docker container for remote development.
    • 01:20:18 – What are the plans for more native Docker support? What are the plans for optimizing performance of the remote development features in CLion?
  • Embedded development with CLion
    • 01:23:45 – A short demo of working with the Arduino boards in CLion.
    • 01:34:55 – What about improvements to debugging experience for the embedded targets, for example viewing the peripherals?
  • 01:38:25 – Working with CTest in CLion
  • 01:46:21 – General questions and final links.


Most interesting questions from the session

50+ questions were asked during registration, and 80+ came online. There were many duplicates, which made us realize that a few key topics required more attention from our side. We handled the questions during the webinar and followed up on some by email afterwards. Still, there are a few questions worth mentioning here, along with the answers.

Q: Template and generic programming debugging can be a pain compared to standard programming. Any tips to improve error/exception visibility and verbosity?
A: We can recommend a couple of tools here: Metashell and Templight. In the future, we plan to get some of these tools or some similar approaches integrated natively into CLion (CPP-4745).

Q: What would you recommend for improving CLion’s performance on my project?
A: Please check these Performance Tuning Tips from our webhelp. With any particular issue, please contact our support (clion-support@jetbrains.com) or file a detailed report in our tracker.

Q: Any plans for native support for Meson?
A: No clear plans for now (CPP-4926), but you can open Meson projects in CLion via compilation database (see this short instruction).

Q: What are your plans for more native Docker support? Not over ssh but just using Docker exec to perform Docker commands with mapped drives and no rsync.
A: First of all, there’s a feature request you can follow for updates and comments – CPP-13751. The great news is that we are considering making these improvements as soon as possible. However, there are lots of open questions and interesting implementation challenges.
For example when we build the project model and collect compiler information (header roots, defines, compiler features, all the stuff that’s needed for correct code assistance), we may run the compiler thousands of times. For docker exec this means that for each compiler call, we have to start the docker container, execute the command… and repeat it again and again (start, execute), thousands of times. So the question is, how does the performance of the direct ssh connection compare to docker exec? We still need to investigate this.
And while we agree that project files synchronization is not needed, it’s not clear what we should do with the header roots inside the docker container.
Finally, we’d like to say that some preliminary support might come to CLion as soon as in v2020.2 or v2020.3.

Q: What are your plans for improving the performance of remote development in CLion?
A: The performance of building the CMake model is the most painful step right now (CPP-14984). This happens because the "Reloading CMake Project" step does not just run remote CMake, but it also includes processing CMake output and collecting compiler information (tons of remote compiler calls). So the plan is to reduce the number of remote process calls while collection compiler information. Other fixes include:

  • Do not transfer unnecessary (binary) build artefacts to the local machine (CPP-15095).
  • Improvements to remote project file transfer speed (CPP-14365, CPP-15396).

Q: Do you have any plans to integrate CTest into CLion?
A: We do not plan to directly support CTest at this time. The reason is that CTest pretty much duplicates the functionality of CLion run configurations. This is how you can use CTest via CLion’s built-in Run/Debug configurations:

  1. Open Run | Edit Configurations…
  2. Create a new one using the CMake Application template. Rename it to CTest, for example.
  3. Select All Targets in the Target field.
  4. For the Executable, do Select Other and find ctest executable.
  5. Define Working directory as macro $CMakeCurrentBuildDir$.
  6. You are all set. Simply run the newly created configuration.

Please see the webinar recording for the demo (01:38:25).

Q: How do I set up reversible debugging in CLion?
A: CLion currently doesn’t provide this feature out of the box, but you can set up reversible debugging with the Undo plugin. Please read this blog post and watch this live webinar recording for the details.

Q: How are Conan / package managers supported in CLion?
A: While no native support exists for now, there is a nice plugin from JFrog to integrate some Conan workflow into CLion. Check out this blog post for a quick start.

Q: Is there a guide for getting started with CLion plugin development?
A: Sure: https://www.jetbrains.org/intellij/sdk/docs/intro/welcome.html. Feel free to direct to us any questions you might have.

DOWNLOAD CLION

Your CLion team
JetBrains
The Drive to Develop

What’s New in IntelliJ Rust

$
0
0

In this post, we’ll take a look at the updates that IntelliJ Rust has received over the 2020.1 release cycle.

But before we start, we have an exciting announcement that we would like to share. It is now possible to debug your Rust code in IDEs other than CLion! Here are a few more details:

  • It’s available in IntelliJ IDEA Ultimate, AppCode, and RubyMine starting with version 2020.1.
  • It works with LLDB on macOS and Linux.
  • It requires the nativeDebug plugin to work in IntelliJ IDEA Ultimate.
  • It requires you to download the debugger binaries, which are not bundled. The IDEs will prompt you to do this.

Now, let’s get back to the plugin updates:

Improvements to LLDB support

If you are working on macOS or Linux, you have the choice to use LLDB as your Rust debugger. LLDB doesn’t natively support Rust and treats it as C code by default, so the plugin has to do its part to make your debugging experience more convenient. You can track the progress of this ongoing work in this umbrella ticket.

As a basis for improving LLDB support, we took the ‘rust-enabled lldb’ patches developed by Tom Tromey, fine-tuned them to suit the recent versions of the debugger, and applied them to CLion’s bundled LLDB.

This patched version of LLDB brings long-awaited improvements in type representation. Now the debugger can properly show enums and primitive types like i32, which was previously displayed as a C-style int.

The patched version of LLDB is also capable of demangling Rust function names, which allows the plugin to show them in a human-readable format inside the call stack (notice the Frames pane in the screenshot below). Moreover, demangled names are now available for Evaluate Expression. Simple function calls like fn foo() -> i32 can already be included in the expressions, and we are working on handling more complicated cases.

LLDB types rendering

Rust REPL

A major novelty of this release is the REPL console, an interactive read-eval-print-loop environment for prototyping and testing your code. This handy tool is a notebook, a calculator, and a Rust interpreter all in one.

Implemented on top of the evcxr_repl utility, Rust REPL provides syntax highlighting and completion for the code lines you type. It also shows a pane with the list of variables, functions, and structures currently in use.

To open the console, call Tools | Rust REPL or search for REPL in the Find Action dialog (Ctrl+Shift+A on Windows/Linux, Shift⌘A on macOS). The plugin will ask you to install the appropriate version of evcxr_repl, and then you’ll be ready to go.

Rust REPL

Updates to language support

The first change to note here is the introduction of code insight for impl blocks with type aliases. For performance reasons, this has been enabled only for types with fewer than a predefined number of aliases (the threshold is set to 10 at the moment).

Completion for impl blocks with type aliases

Another important improvement concerns type inference. It now covers subslice patterns and, in some cases, const generics:
Type inference for const generics

Editor enhancements

Code insight has also received some improvements. If some of the local variables or parameters are never used, you will see them highlighted in grey:

Unused local variables

The return type mismatch check is now equipped with a quick-fix:
Quick-fix for return type mismatch

A new inspection, Lift return, identifies if and match expressions where return can safely be pulled up from the branches:

Lift Return intention

And the list of refactoring intentions has been enriched, as well. You can now extract enum variants into separate structures and edit them while simultaneously affecting all usages:
Extract enum variant

____________

Those are the most notable changes we’ve made to IntelliJ Rust for the 2020.1 release. Please share your feedback with us, and if you encounter any issues, don’t hesitate to report them in the plugin’s tracker. Thank you!

DOWNLOAD CLION 2020.1

Your Rust team
JetBrains
The Drive to Develop

Learn Productivity with CLion: Tips & Tricks Demo

$
0
0

In May 2019, the JetBrains team attended several events in Israel. We were inspired by the fantastic and welcoming C++ community in Tel Aviv, the old city of Jaffa, and Haifa. While the main goal of the trip was a brand-new conference – Core C++ (check out the trip report), we also had a great evening at the Haifa::C++ meetup and even ran our own event – JetBrains Night Tel Aviv 2019! We gave several talks there on C++ and .NET development in general and our tools in particular. In this blog post, we’d like to highlight one of those talks.

What does it mean to be productive when developing in C++? Can a tool help us become a language guru? Are there tricks my IDE can teach me to make C++ coding a bit easier? These were the questions I tried to answer in my talk – “Can You Make Me Productive with a C++ IDE?”. Today I want to share the recording of this presentation along with a few comments and timestamps that you can use to jump to the most interesting parts. You might even learn a trick or two from the talk!

There are dozens of great tools in our ecosystem, and each of them is honed to be really good at certain tasks. But gathering them all in one place and combining them inside one user environment can be tricky. This is the job for an IDE – an Integrated Development Environment, specifically designed to provide a universal cross-platform environment in which you can work with C++ in the most effective and efficient way possible. An IDE integrates tools and sources, from the project model and the debugger to version control systems, profilers, memory checkers, the built-in terminal, and more. It works both for local and remote setups, for WSL, or simply doing remote (or even on-chip) debugging.

With a powerful tool like that, you need to know how to use it. Let’s go over a few tips on how you can get the most out of CLion!

Note that the video was recorded in May 2019, so some things have already been improved since then, and the UI may have changed in several subsystems. Please refer to the CLion web documentation to learn the details.


2:41 Come on, IDE, can you generate code for me? Can I sit here and have you write code for me? This is what I call productive laziness. The Generate menu (Alt+Insert on Linux/Windows, ⌘N on macOS) will help generate getters and setters, constructors, destructors, definitions and even operators, and will override and implement functions. With another shortcut – Alt + Enter – you can start using an entity before actually declaring it.

6:40 Update hierarchies while refactoring automatically to keep your code correct. CLion can actually propagate changes (with your confirmation, of course) to the top of the tree and then back down through all the branches.

8:00 Documentation is obviously one of the most valuable artifacts produced by developers. It helps you maintain your code and clarifies any parts that are not self-explanatory. In CLion, the Quick Documentation popup (Ctrl+Q on Linux/Windows, F1 on macOS) not only provides info on the function signatures and code documentation comments, but also shows inferred types and macro replacements. Documentation stubs can be generated and will be updated automatically when you update the function signature.

12:33 Highlight the proper preprocessor branch in CLion by selecting a resolve configuration in a switcher. This is the superpower it gives you when targeting several platforms in your code.

14:08 As you may know, CLion comes with dozens of static code analysis checks. Some of them come from CLion’s own language engine, others from Clang Analyzer and Clang-Tidy, and there are even more that are written by our team on top of the Clangd language engine. It can detect things like a function that hides a non-virtual function from the parent class, a format specifier that is missing the actual variable type, detailed overload resolution errors, missing C++-style casts, unreachable code, arguments being passed in the wrong order, and many more.

23:54 The ‘inconsistent naming’ check takes care of the naming convention you’ve defined for your project. Learn the predefined options and find out how you can configure your own style in CLion.

25:42 With its automatic refactorings, the IDE lets you make code changes safely. When refactoring the code, all the context usages are appropriately updated (not text search-based!). Watch the demo to learn how to add or update parameters via Change Signature, extract all occurrences at once, or even move members up and down through the class hierarchy.

29:03 When you develop locally but not on the target machine, you may need to debug remotely. Learn these very simple steps for configuring GDB Remote Debug in CLion. Also, read about this slightly different option in our web help.

33:44 Sometimes the whole cycle of development has to be remote, but you want your CLion running on a local machine. We call this Full Remote Mode. Check out this part of the demo to learn about configuring that and about what happens in the background when the connection is established and the project is reloaded in CLion.

36:45 Valgrind memory check integration in CLion helps you catch memory leaks in your code. Check the traces and jump easily to the source code from the tool window with the Valgrind results to vanquish the problem.

38:11 Check all possible kinds of memory issues with Google Sanitizers. Watch the demo to learn how to pass the -fsanitize flag and enable the integration similar to Valgrind.

39:40 Profiling with CLion is possible on Linux (via perf) and Mac (via DTrace). Use flame charts, refer to the call tree, and jump to source to investigate likely performance issues in your codebase. See our web help for more details about the Dynamic Analysis tools integrated in CLion.

40:36 Unit testing is part and parcel of the development workflow, which ensures that changes you introduce do not break your code. Learn how CLion can empower you when using frameworks such as Google Test, Catch, or Boost.Test. Also check out our web help for some good practices to keep in mind when unit testing.

42:48 A few words on CMake integration. Learn about code completion, navigating via file names, live templates, and installing CMake.

By the way, the full transcript of the video (English only) is also available.

Please let us know if you enjoyed this format. Any questions, ideas, or suggestions? As usual, please voice them in the comments below!

DOWNLOAD CLION

Your CLion team
JetBrains
The Drive to Develop

Live Webinar: CLion 101 and Beyond

$
0
0

Are you new to CLion or have you been wanting to try it out? Then this webinar is for you!

From a standing start, we’ll get you not just up and running with CLion, but get you super productive right away – and set you on the path to hyper-productivity!

blog_1600x800

Agenda

We’ll cover installation (briefly), finding your way around the UI, the fastest way to access any action in the application, and how to set things up the way you like them. We’ll then see how you can use CLion to full advantage as an ongoing assistant for your code, showing you where you might have gone wrong – and even how to fix it! We’ll also show how you can navigate huge and complex codebases like a pro, and even get CLion to write or refactor code for you.

Finally, we’ll look at how to run and debug code in different ways – even on remote machines.

Speaker

Our speaker is Phil Nash. Phil is the author of the C++ test framework, Catch2, and composable command line parser, Clara. As Developer Advocate at JetBrains he’s involved with CLion, AppCode and ReSharper C++. More generally he’s an advocate for good testing practices, TDD and using the type system and functional techniques to reduce complexity and increase correctness. He’s previously worked in Finance and Mobile as well as an independent consultant and coach specialising in TDD on iOS.

Join us on Tuesday, June 23, 5pm CEST | 3pm GMT | 8am PDT.

Register now!

Your CLion team
JetBrains
The Drive to Develop


CLion 2020.1.2 Bug-fix Update

$
0
0

The second bug-fix update, CLion 2020.1.2 (build 201.7846.88), is now available for download. Get it from our website, via the Toolbox App, or via snap (for Ubuntu). A patch update will be available shortly.

DOWNLOAD CLION

Here are the main highlights:

  • Performance improvements cover cases with laggy typing (CPP-19613, CPP-16207) and slow runs of Google Tests (CPP-20012).
  • Improvements in C++ support including:
    • Quick-fix which suppresses the Unused warning with the [[maybe_unused]] attribute is now more accurate:
      Maybe unused quick-fix
    • Data Flow Analysis inside virtual functions is disabled.
    • Fixes in Clangd-based code completion.
    • New formatter options for spaces before and after the colon in bit fields.
    • And many other small fixes in code analysis.
  • Fixes for CUDA development:
    • Code highlighting no longer breaks after a CUDA kernel code (CPP-20356).
    • Support for the __device__ and __host__ attributes before parameter lists in lambda expressions.
    • A regression which caused CUDA run configurations to disappear in the previous 2020.1.1 update has been fixed (CPP-20178).
  • Fixes for embedded development:
    • When collecting IAR compiler info, CLion no longer actually builds the project. So projects with the IAR compiler will be loaded in CLion successfully even if some compilation errors are present (CPP-19327).
    • The PlatformIO plugin got a significant update:
      • Highlighting in platformio.ini files is enabled:
        PlatformIO
      • CMake Profiles are created for the CMAKE_CONFIGURATION_TYPES entries in PlatformIO CMake projects (CPP-19478).
      • Various Run/Debug Configurations for running PlatformIO-based projects are now added automatically when a new project is created.
      • The PlatformIO build directory is excluded from the project indexing.
      • PlatformIO actions are now available in Find Action dialog.
  • Unit testing:
    • CLion now supports Catch2 template tests:
      Catch2 template test
    • Fixes for Google Tests in CLion’s built-in test runner, which was not always correctly reporting successful tests.

The full release notes are available here. And stay tuned! The EAP program for the upcoming 2020.2 release is just around the corner 😉

DOWNLOAD CLION

Your CLion team
JetBrains
The Drive to Develop

CLion Starts 2020.2 EAP: Performance Fixes, Catch2 and PlatformIO Integration Enhancements, New CMake Actions, and More Accurate Code Analysis

$
0
0

We’re ready to launch the CLion 2020.2 Early Access Program!

We still have an interesting path ahead of us, but we are now ready to show you some of the valuable improvements we’ve made and to get your feedback. So please join us for this EAP – we’d love to welcome you aboard!

As usual, the EAP builds are free to use and no license is required. The main goal is to test the tools in all kinds of non-standard and unusual environments you may have set up, so we can make sure we haven’t missed anything. If you come across any bugs or peculiar behavior, please report them to our issue tracker so we can collect and fix as many issues and regressions as possible.

DOWNLOAD CLION 2020.2 EAP

Build 202.5103.16 is available from our website, via the Toolbox App, or as a snap package (if you are using Ubuntu).

CLion 2020.2 EAP

Here are the main highlights:

Performance

When you type in the editor, the IDE reparses the corresponding code pieces on the fly to provide you with some smart assistance. Typing inside a macro definition can be tricky for the IDE, as it has to correctly understand the moment the macro ends and the regular code starts in order to update the AST accordingly. To avoid editor performance degradation, CLion now inserts a backslash on pressing Enter inside the macro definition. The macro definition will quite likely be continued on a new line, so the IDE inserts the backslash for you automatically before moving the caret to a new line.

This EAP build also comes with a fix to the IDE freeze that was happening when Sanitizer’s output visual representation was enabled (CPP-16010), as well as a fix to infinitely reading the profiler output in some cases (CPP-20096).

We’ve also reworked the documentation popup to avoid several cases where it blocked the UI.

Unit testing

In terms of Unit testing frameworks, CLion comes with support for Google Test, Catch(2), and Boost.Test. This EAP brings support for Catch2 template tests. They are now recognized and handled just like the other test types:
Catch2 template tests

Debugger for Microsoft Visual C++ toolchain

On Windows, you can select from MinGW, Cygwin, WSL, and the Visual Studio toolchain. In the case of the latter, a debugger implemented by JetBrains based on LLDB is used and it has been given a significant number of improvements:

  • Debug sessions no longer freeze on stop. (This used to happen when the target process spawned another child process that was later detached.)
  • A bug when child members weren’t shown for some values is now fixed.
  • Threads are now named automatically based on their entry-point function.
  • The debugger got significant performance improvements, and many freezes and crashes were fixed.
  • Fixes for stepping issues in multithreaded code, fixes for floating-point type variables and arguments, and much more.

Code analysis and refactoring improvements

The ‘unused code’ inspection now works for type aliases and detects when they are not used. This works for globally and locally defined using:
Unused usings

In CLion 2020.1, Data Flow Analysis was moved to the Clangd-based language engine to enable it to be more accurate and less heavy in terms of performance. We are continuing to work in this direction and have introduced several fixes for DFA-related problems in CLion 2020.2 EAP, including:

  • False warning about unreachable code (CPP-19266).
  • Invalid code block highlighted when an endless loop is detected (CPP-19084).
  • False warning Condition is always false when a value is changed from pointer (CPP-3583).
  • Duplicated DFA notification, and more.

Additionally, CLion no longer suggests replacing the if constexpr condition with the ternary operator – which only makes sense for a regular if else condition. And the Rename refactoring doesn’t fail incorrectly with a Local variable already exists in the scope error (CPP-3054).

Updates to the PlatformIO plugin

CLion 2020.1 introduced a plugin for PlatformIO that helps you start an embedded project faster. A new version is now available and it has been given several significant improvements:

  • Highlighting is now available in platformio.ini files:
    PlatformIO ini
  • Many useful Run/Debug Configurations for running PlatformIO-based projects are now added automatically when a new project is created (previously, only configurations for debug and upload were created).
  • CLion now creates CMake Profiles for the CMAKE_CONFIGURATION_TYPES entries in the PlatformIO CMake project (CPP-19478):
    PlatformIO configurations

CMake IDE actions

There are a few actions for CMake projects now available in Find Action. You can call them from there, or assign a shortcut to any or all of them if you use them often:

  • CMake Settings
  • Stop CMake project reload
  • Open CMakeCache file

CMake actions

VCS: GitHub Pull Requests

Support for GitHub Pull Requests has been improved significantly with 2020.2. You can now fully interact with all the pull requests associated with the repository:

  • Welcome a new and more spacious view for GitHub Pull Requests. Simply double-click on any pull request you need from the list, and the IDE will display all of the information about it, including messages, branch names, author, assignee, changed files, commits, timeline, and more:
    GitHub PRs
  • View the results of pre-commit checks in the dedicated panel.
  • Start a review, request reviews, attach comments, and submit reviews – all from within the IDE.
  • View and interact with comments, both commit level and line level.
  • Merge pull requests from within the IDE.

No more switching to the browser or another tool! The entire Pull Request workflow is at your fingertips in CLion and other IDEs on the IntelliJ Platform. Learn more.

Clangd-based engine update

For quite some time now we’ve had two language engines in CLion – CLion’s own engine and another one that we implement on top of Clangd. The latter is used for code highlighting, completion, code analysis (together with our own code inspections), some navigation actions, and more. We’ve had this engine enabled by default for several releases now and we’re seeing encouraging feedback from our users. We constantly improve it by fixing any cases when the engine crashes or behaves incorrectly, and we do our best to stay aligned with the latest LLVM Clang version. The original CLion engine is not evolving fast enough and many actions in CLion now rely on the Clangd-based engine.

So from now on, the Clangd-based engine is the default language engine in CLion and the option to turn it Off has been removed. Instead, if you experience any issues with this engine, please report them to our team. We’ve also added some information about the LLVM Clang revision used for the Clangd-based language engine so that you know what to expect in terms of C++ support and built-in Clang-Tidy checks:
Clangd settings

And more

Other important fixes include:

  • When you have several independent projects opened in CLion, builds were previously running in sequence (which means one build running was preventing another one from starting). Now they run in parallel.
  • The Recompile single file action is now available for Ninja and other generators used in CMake and supported in CLion.
  • Fixes to Clangd-based completion to make it more accurate and reliable (CPP-19807, CPP-19990, CPP-20121, CPP-20276, CPP-20352).
  • A new setting to specify the default encoding for consoles (used to decode process output) is now available in Settings/Preferences | Editor | General | Console.

The full release notes are available here. There are more than 100 fixes included, so make sure to try out the new EAP build today!

DOWNLOAD CLION 2020.2 EAP

Your CLion team
JetBrains
The Drive to Develop

Doctest for unit testing in CLion

$
0
0

In the C++ ecosystem there is more than one unit testing framework. Google Test is the one used the most. Boost.Test is obviously gaining in popularity among the Boost community. Catch(2) is relatively new but also growing impressively. Meanwhile, several years ago at CppCon there was an inspiring presentation by Viktor Kirilov of yet another framework called doctest. Viktor told our audience about it in the guest blog post in ReSharper C++ blog, once the support was added there.

In a nutshell, doctest is a fast single-header framework, with self-registering tests. It’s safe: uses thread-safe asserts and can be used without exceptions and RTTI. You can learn from the post in detail what makes doctest interesting.

The good news is – doctest is coming to CLion 2020.2 EAP! Grab the free EAP build and give it a try now.

DOWNLOAD CLION 2020.2 EAP

The corresponding plugin is bundled into the EAP build:
Doctest plugin
Both CLion and ReSharper C++, now provide support for 4 frameworks: Google Test, Boost.Test, Catch(2), and doctest.

Let’s take the doctest project from the GitHub and check out how the sample tests look in CLion:
Doctest run

If you already use Google Test, Boost.Test or Catch(2) integration in CLion, you are familiar with what’s available here:

  • Doctest tests are detected by CLion and Run/Debug configurations are created automatically when you run a test or all tests in a file.
  • Built-in test runner shows the results of the tests, along with the test output, test duration, and a bunch of controls that enable you to monitor the tests and analyze the results.
  • Run/Debug icons in the left gutter show the status of the tests.

That’s it! You can try out doctest for your project in CLion and benefit from the integration! Let me just add a few notes on the Run/Debug configurations here. In doctest there are suites, tests, and subtests. Run/Debug configurations in CLion use a Pattern field in the settings to define the set of tests to launch within this configuration.

  • To run all tests in a file use pattern [#*filename.cpp].
  • [suite_name] will run a suite with the corresponding name.
  • If you want to run a particular test from a given suite, you can point [suite_name][test_name]. Adding another level for subtest is also possible: [suite_name][test_name][subtest_name].
  • An anonymous suite is possible via []. However, not without a test name (so [] or [][] run nothing).
  • Patterns can be combined using commas as separators.

Doctest configs

DOWNLOAD CLION 2020.2 EAP

P.S. Many users ask us about CTest support in CLion (CPP-905) and we tried to address the point during the CLion AMA session in May. While another unit testing framework was taken on board, CTest is still not there. There is a workaround of course, but that’s definitely not an experience our users expect from us. We’ve recently conducted a small overview research trying to understand how CTest is usually used, what commands are regularly passed as a test script, what kind of support is provided for CTest by other IDEs. And while we see some challenges, like the very custom scripts used to run tests or deploy the environment, difficulties to detect the exact executable to debug, and others, we plan to prototype the support in the further CLion versions. Our call to action here would be – share your OS projects with us if you use CTest so that we can learn about more use cases! Thanks in advance.

Your CLion team
JetBrains
The Drive to Develop

Makefile projects in CLion: now public!

$
0
0

CLion 2020.2 EAP2 brings long-awaited Makefile project support. While it’s still in its early stages with various limitations and known issues, it’s good enough to cope with a long list of projects already.

Do you have a Makefile project? Grab the free EAP build and give it a try now. Share your feedback with us!

DOWNLOAD CLION 2020.2 EAP

In this blog post we’ll answer:

Our approach to implementation

Some time ago we presented our findings and the approach we took to support Makefile projects in CLion. There we overviewed the approaches to handle Makefile that are preferred by various modern C++ IDEs and editors:

  1. Compiler wrappers are used to wrap the actual compiler calls and then a full clean build is performed and the project information is extracted.
  2. LD_PRELOAD environment variable is used and a specific dynamic library is loaded before the execution of any build process to intercept the compiler calls and collect project information.
  3. The output of the make command is parsed, often used with the --just-print option to avoid actual build.

The 3rd option provides several very important benefits:

  • It doesn’t affect the build process.
  • It allows us to collect the information quicker compared to the full project build.
  • This would work as a ‘portable’ option, as the IDE can theoretically start with the Make output recorded on another machine.

So we took the 3rd approach and implemented a prototype. We’ve tested it on a long list of projects, which you may find on our confluence page. And we hope it also performs for a huge variety of others. So it’s time for you to give it a try on your Makefile project and share the feedback with us!

How to start with your Makefile project in CLion

To open a Makefile project in CLion:

  1. Select the project in File | Open.
  2. You can open a folder as a project and CLion will search for the top-level Makefile (as well as CMakeList.txt or compile_commands.json files) and suggest opening it as a project. Or directly point CLion to a Makefile in the Open dialog.
  3. CLion might ask you to Clean the project. This is required as the Make build is incremental and when run on an uncleaned project only the updated files will be compiled, so project reload won’t work correctly and will miss all the unchanged files.
  4. CLion will now try to load the project.
  5. When the project is loaded successfully, you can start working with it in CLion and benefit from all the smart IDE features it provides.

Makefiles in action

There are important settings you can tune if the defaults don’t work for you. Go to Settings/Preferences | Build, Execution, Deployment | Makefile settings:
Makefile settings

Here you can change:

  1. Toolchain used to load the Makefile project. All local toolchains (Clang, GCC, MinGW, Cygwin, WSL) are supported. Visual Studio toolchain relies on NMake, which is currently not supported, but if you manage to build your project using GNU Make then it will work in CLion. Remote mode is not yet included.
  2. Arguments used to call the make command in CLion to extract the project information.
  3. Build and Clean Make targets used along with the make command in CLion to extract the project information. For Build, an empty field means CLion takes the first target specified in the project’s Makefile.

Here are a few final tips for you to work with a Makefile project in CLion:

Tip 1: CLion searches for targets in your Makefile project so that you can start using them in the Run/Debug configuration instantly:
Makefile configurations
And if CLion fails to find your Make target, you can create a Custom Build Target with type Make and use it in the configurations:
Custom makefile targets

Tip 2: Out-of-source builds are supported, but you’ll likely want to call Tools | Makefile | Change Project Root after the project loading to get your sources presented nicely in the Project View.

Tip 3: Currently, CLion doesn’t update or reload the project automatically on any file changes, like for example adding a new file. The notification on the Makefile will appear after you update it, so that you don’t forget to reload the project. However, if the configure step is used for your project, don’t forget to call it first to update the Makefile and get the notification.
Makefile updated

What can I do if something goes wrong and my project fails to load correctly?

We’ve tested it on a long list of projects, which you may find on our confluence page. And we hope it also performs for a huge variety of others, including yours. However, if you meet any issues, here is a list of actions you may take:

  1. Check the Toolchain you are using in Settings/Preferences | Build, Execution, Deployment | Makefile settings. You should be able to build the project in the selected environment.
  2. Check reload arguments and build target in Settings/Preferences | Build, Execution, Deployment | Makefile settings. Most of the projects which worked successfully for us were fine with the default argument, but you might need some changes there in your case.
  3. Try Tools | Makefile | Clean and Reload Makefile Project.
  4. If the steps above don’t help, try cleaning the project from the /makefiles in the system directory. For example, for the postgres project on my macOS, it’s ~/Library/Caches/JetBrains/CLion2020.2/makefiles/postgres.dc29ef09. Reload the project after that.
  5. Finally, if all the tips from the above don’t work for you, go to Help | Diagnostic Tools | Debug Log Settings… and turn on the debug logs by adding #com.jetbrains.cidr.cpp.makefile. Then reproduce the problem and submit the logs to our tracker or support.

Known issues and limitations

The most fragile part of the algorithm used is extracting the compilation commands from the make command’s output. We have found issues happen in some cases:

  • The project is suppressing printing the directories. And so the algorithm fails to correctly detect which source files are actually being built.
  • The compiler is unknown or compilation flags can’t be correctly extracted. Various wrappers like libtool make things worse by hiding the compilation flags and interfering in the Make’s output (CPP-19549, CPP-19305).

We’ve put several heuristics in to overcome the cases like that we’ve experienced on our test projects. The users can also control the arguments used to call the make command while extracting the project information: Settings/Preferences | Build, Execution, Deployment | Makefile | Arguments.

What’s next?

  • There is a Makefile support plugin which provides code highlighting and some support for building make projects. The plan is to rework and bundle it into CLion (CPP-16933).
  • Unit testing integration will be enabled for Makefile projects later (CPP-20718).
  • Add an ability to link Makefile to an existing project (CPP-20733).
  • Changing toolchain or other settings affecting the project load should trigger the reloading (CPP-18982).
  • To expand the support to GNU Autotool projects, allow users to set up the "pre-configure" step for Makefile projects (CPP-16924).
  • Support non-GNU Makes (NMake, BSD) (CPP-18723).
  • Implement the approach with compiler wrappers and make it work in combination with the current one.

But before all that, we plan to polish the current prototype and fix various issues. And at this point your feedback is really important and valuable. Please report any issues you face to our issue tracker.

Mind the list of projects we’ve already tested our prototype on: Makefile projects in CLion.

DOWNLOAD CLION 2020.2 EAP

Your CLion team
JetBrains
The Drive to Develop

CLion EAP 2020.2: Makefile Projects in CLion, Doctest Support, More Accurate Code Analysis Checks

$
0
0

Hi,

Last week we launched CLion 2020.2 EAP. The first EAP build included dozens of fixes across several areas, including performance improvements, unit testing tuning, VS toolchain debugger enhancements, an update in the PlatformIO plugin, and fully manageable GitHub Pull Requests right in the IDE. The second 2020.2 EAP build is now ready, and we’re sure you’re going to like it!

Build 202.5428.21 is available from our website, via the Toolbox App, or as a snap package (if you are using Ubuntu). A patch-update is ready for anyone using the previous 2020.2 EAP build:

DOWNLOAD CLION 2020.2 EAP

The changes implemented in this build are so enormous that we’ve had to split them up into three blog posts just to cover all the updates. We have three big things for you to preview in this build:

Simplify and loop conditions code analysis check

In this EAP build, we’ve updated two useful code inspections to work more accurately on C++ code.

Code can often be simplified but it’s not always easy to see how. CLion will show you! In 2020.2 EAP we implemented a massive overhaul of the Simplify code inspection – we moved it to our Clangd-based engine to increase its accuracy and have added more use cases for it to cover.

The inspection can now simplify these types of statements:

  • condition == true.
  • condition1? true : condition2.
  • if(condition1) return true; return condition2;
  • Statements for identical branches.

Simplify if(true) and while(false) is also possible. If you feel the inspection is too annoying in your code, turn this case off in the inspection’s options: Settings/Preferences | Editor | Inspections | C/C++ | General | Simplifiable statement.

This might sound like it should have been simple, but if you add macros and templates into the equation, things soon become more complicated.
Simplify quick-fix

The inspection is configured in Settings/Preferences | Editor | Inspections | C/C++ | General | Simplifiable statement.

Another incredibly useful inspection is the Loop condition is never updated, which detects situations where a loop condition is not updated inside the loop. Situations like these can cause an infinite loop, which is not usually the desired outcome. This code inspection now uses Data Flow Analysis (which was moved to our Clangd-based engine in v2020.1).

You might already know that there is a very similar inspection in Clang-Tidy – clang-tidy:bugprone-infinite-loop. However, it doesn’t work for loops with exit points and throws up false positives in cases with lambdas or references. CLion’s own inspection is based on DFA and is intended to be more reliable in all these scenarios. If this proves to be the case, we’ll later disable the Clang-Tidy check in the default inspection profiler (CPP-20575).
Loop conditions checks

Full release notes are available, as usual, as a list. And you are welcome to provide us with your feedback using our tracker or in the comments section below.

DOWNLOAD CLION 2020.2 EAP

Your CLion team
JetBrains
The Drive to Develop

Viewing all 678 articles
Browse latest View live