CLion opens 2018.3 EAP: initial remote dev support, unit testing performance improvements, and new Search Everywhere and Run anything dialogs

Today we are starting the new CLion 2018.3 Early Access Program! There are big plans for this release, and we will do our best to achieve as much as possible. We welcome all of you to give the new features and enhancements a try, and share your feedback with us.
800x400_blog@2x
Find below a detailed description of the following new features and improvements:

Download CLion 2018.3 EAP

Initial remote development support

A while ago we started working on remote development support in CLion. And in this EAP we are excited to announce that we have already been able to add initial support which is ready for you to try! It works for Unix-like (macOS, Linux) local client machines and Linux as a remote host. We assume that your source files are on the local machine and that CLion will automatically synchronize them to the remote host. With just a simple configuration step you can get CLion, which runs locally, to build, run, and debug your application and its tests on a remote machine. For more details, please, refer to this detailed blog post.
remote run ap

Unit testing

Performance

CLion integrates with Google Test, Boost.Test, and Catch frameworks for unit testing. The integration provides you with a built-in test runner, framework specific Run/Debug configurations, icons in the left gutter which report the status of the tests. In the case of Google Test, there is also a test generating feature that helps to create test and test fixture stubs. In this EAP we’ve reworked the whole integration in order to resolve dozens of performance issues (UI freezes when navigating to test results, performance issues when completing test macros, etc.). There has been a huge amount of work gone into reworking the whole integration which will hopefully make your work with unit tests in CLion much more pleasant thanks to the more responsive UI.

Show Test List

Test detection in CLion is implemented in a lazy manner to reduce indexing times. Thus for diagnostic purposes, we’ve implemented a new action “Show Test List”. You can call it from the Find Action dialog, and it will open a text file with a list of all the tests (Google Test, Boost.Test or Catch frameworks are detected) currently detected in the project. Note, the action currently doesn’t trigger test indexing.
show test list

Output processing

We have introduced a few fixes in this build to get more accurate test results’ processing:

  • Google Test: Problems with the colored output (CPP-10823)
  • Google test: cerr output not shown in UI (CPP-10821)
  • Tests with a non-ascii name are now recognized (CPP-11497)
  • Google Test: printing in stdout/err breaks output (CPP-4780)
  • CLion now supports OpenCV GTest modification (CPP-13680)

Quick Documentation: formatted macro expansion

The Quick Documentation popup is really handy when you work with macros, as it shows you the final macro replacement, so you can quickly understand the code that will be substituted after the preprocessor pass. But when you have a complicated deeply nested macro, the final replacement might not work for you if not formatted properly. That’s why CLion now formats the macro replacement in the Quick Documentation popup and also highlights strings and keywords used in the final substitution. For example, this is how it looks for the Boost.Test macro:
boost_test_replacement
And here is the replacement for the Catch test macro:
catch_test_replacement

Validation for compilation database files

CLion 2018.2 introduced compilation database project model support. Which meant that you could now open compile_command.json files, created in advance, as project files in CLion. In this version, we’ve added specific inspections to check the compliance with the compilation database JSON schema. For example, it notices when you use a wrong type:
comp_db_compliance
or miss the property completely:
comp_db_compliance_2

New Search Everywhere

The new Search Everywhere popup was introduced in all IntelliJ-based IDEs in 2018.3 EAP. Our main goal was to solve a lot of the annoying issues with dialog performance, losing focus, incorrect resize, and other things like this.
Moreover, now this popup incorporates several actions at once: Search Everywhere (Double Shift), Find Action (Ctrl+Shift+A / ⇧⌘A), Go to class (Ctrl+N / ⌘O), Go to file (Ctrl+Shift+N / ⇧⌘O), and Go to symbol (Ctrl+Alt+Shift+N / ⌥⌘O) action. Each one has its own separate tab in the dialog, and you can use TAB to switch between these tabs. And all the specific action shortcuts still work, so for example, Ctrl+N / ⌘O will open Classes tab:
search everywhere

Universal Run Anything dialog

Another universal dialog in IntelliJ-platform IDEs is called Run Anything, and you can open it with Double Ctrl. It allows you to:

  • Search and launch any configuration
  • Open a project (just type “Open” and select the desired project from the list)
  • And even debug any configuration of your choice (hold down the Shift key, and the dialog will switch to Debug Anything mode)

run anything

Other improvements

Among the other important changes we’d like to highlight:

  • The “Mark as Plain Text” action is now available in CLion. It allows you to remove big and complicated files from indexing, so disabling smart assistance for such files (for example, code completion, navigation, refactorings) and improving the IDE’s performance. And you can easily revert the files back at any time from the context menu.
  • CLion now parses C++17 fold expressions and C++17 deduction guides correctly. For the user this means not only less false code highlighting, but also better code assistance, for example, for the user-defined deduction guides:
    deduction_guides
  • Bundled GDB version was updated to 8.2.
  • An important issue with CMAKE_TOOLCHAIN_FILE was fixed in this version. A bug caused system include directories and system #defines to be incorrectly detected, which lead to the incorrect coding assistance (CPP-11250).

That’s it for now! The full release notes are available by the link.
Get the new build from our site and give it a try today! Your feedback is very welcome here in the comments and in our tracker.

Download CLion 2018.3 EAP

Your CLion Team

JetBrains
The Drive to Develop

This entry was posted in Announcement, Early Access Preview and tagged , , , , , , , . Bookmark the permalink.

50 Responses to CLion opens 2018.3 EAP: initial remote dev support, unit testing performance improvements, and new Search Everywhere and Run anything dialogs

  1. deflix says:

    Debugger memory view please!

  2. Tano says:

    It’s really great that so many bugs are fixed!

  3. Tano says:

    Question please, not related to this: how can I set the path for external clang-tidy file?
    What path does CLion use? The main CMakeLists or project root? Set via CMake-Change Project Root?

    • Anastasia Kazakova says:

      CLion uses bundled Clang-Tidy executable. If you wish to change it, you can switch in Settings | Languages & Frameworks | C/C++ | Clang-Tidy. Quick question though, why do you need it? Do you have some custom checks implemented over clang-tidy?

      • Tano says:

        I want to change the clang-tidy configuration file, not clang-tidy binary, sorry for the confusion.

        Please check also this fresh bug: CPP-14239, it’s really annoying to have a red folder in the explorer.

        • Anastasia Kazakova says:

          There are two ways to configure Clang-Tidy checks: 1) in CLion settings: Settings | Editor | Inspections | C/C++ | General | Clang-Tidy 2) specify there that you are using .clang-tidy config files. Find more details in our webhelp: https://www.jetbrains.com/help/clion/clang-tidy-checks-support.html#profile

          We do keep an eye on the issue tracker, processing all the requests as soon as possible, at least to suggest some workaround or request additional details. But please be patient. We have a whole bunch of newly created tickets there after the first EAP was started yesterday.

  4. Sebastian says:

    I think the option for aligning multiline function parameters is broken. When I write this:


    void foobar (std::string a, std::string b) {
    ---------------------------^ Hit Enter here

    Then I get

    void foobar (std::string a,
    std::string b) { //Indented with 8 spaces

    but I am expecting:

    void foobar (std::string a,
    std::string b) { //Aligned with s of std

  5. I’m really sad that the ctest ingratiation is not in the road map. We are a paying costumer with an increasing number of licences. we manage huge number of test and execution variation with ctest -> like remote execution on target devices. Today with Clion I have to setup each test deployment, execution in the ide by clicking around. With ctest integration all this would be avoided. Please try to consider ctest integration with higher priority.

    • Anastasia Kazakova says:

      Thank you for your feedback! We do have it in our plans. However in this cycle we are focused on improving the unit testing frameworks integration, especially in terms of performance, but also focusing on unified API. When it’s done, it will be much easier to get CTest on board. Or even open a public API for unit test subsystem in CLion.

  6. Dmitry Nezhevenko says:

    Google Test is still ridiculously slow… I was experiencing a lot of freezes due to some google test calculations… Now with this EAP it doesn’t freeze anymore. But now I’m just waiting for more than 15 mins to ‘Prepare Test Run’… that just prints “Processing file: file_name.cpp” multiple times (with exactly same file name).

    • Anastasia Kazakova says:

      Could you please tell us, do you use all-tests(…) pattern or simply list the tests to run in the configuration?

      Let me explain: we need to find all tests in the file file_name.cpp. if you are using ‘All in file_name.cpp’ configuration with meta-pattern all-tests(file://.../file_name.cpp). There is the way to accelerate the run and replace the all-tests(file://.../file_name.cpp) pattern to the explicite test-list-pattern from Messages|Prepare Test Run|Pattern to run: after the first run.

      • Dmitry Nezhevenko says:

        I’ve just opened cpp file with gtests. Observed that there is no ‘run’ marks near line numbers as before.

        Then I’ve right clicked on editor tab and selected ‘Run all in file_name.cpp’.

        It’s already more than 1 hour since I tried to run it. And it still prepares something… So I was not able to run it first time…

        I’ve posted my comment to CPP-11409 (which is resolved).

        • Dmitry Nezhevenko says:

          PS. At the same time I was able to run unit tests on small hello-world size project. So it’s some sort of scalability issue.

          PPS. I’ve also tried to add #if 0 / #endif after includes. And it doesn’t help

        • Anastasia Kazakova says:

          Let’s proceed in the ticket.

  7. John says:

    Please consider this small but very helpful Doxygen parameter coloring feature:

    https://youtrack.jetbrains.com/issue/CPP-10311

    It’s already implemented in IntelliJ, and CLion already understands parameter names enough to refactor them, so I would hope it would not be terribly difficult.

    This would make reading Doxygen comments much more pleasant for all C and C++ projects.

    • Anastasia Kazakova says:

      Thanks, we’ll do. Not in the nearest plans unfortunately, but will definitely check if we can incorporate it soon.

  8. Roman says:

    I’m surprised that CPP-7361 is still not fixed. For me it makes generators unusable:
    1) Have to wait 1-2 seconds before can I invoke generator
    2) Generated code very often uses wrong signature

  9. Denis Marinov says:

    Why is it taking so much time to build the symbols after creating new and opening existing project? My CPU goes to 100% on my laptop which annoys me. I don’t have this with VS.

    • Anastasia Kazakova says:

      CLion takes all the CPU resources to make the initial indexing or open an existing project and prepare it for using in the IDE. If you feel it’s using too much of the resources, please make and report a CPU snapshot to us.

      • Denis Marinov says:

        I see. It also takes about 14% of the memory, or about 1.3 GB which is huge. Why is it so resource hungry compared to other IDE’s I don’t know. Thank you for the response!

        • Anastasia Kazakova says:

          How do you estimate the memory? CLion is JVM process and by default it reserves 2Gb of RAM. You can turn on the built-in memory indicator in Settings/Preferences | Appearance & Behavior | Appearance | Windows option | Show memory indicator and check the real usage.

    • Roman says:

      Clion maintains two separate code models : in Java and in Clangd. So expect that it will take 2 times more memory than other IDEs. In my project for example Clangd consumes about 1 GB, and Clion/JVM usually use about 2GB.

      • Anastasia Kazakova says:

        BTW, we plan to get deeper with analysing how clangd acquires memory and work in this direction to improve the usage.

  10. Alexey says:

    Does ‘remote development’ planned to work with local docker containers?

    I mean, is it possible to work more straight way having in mind the possibility to directly access sources (via exported folder – no need to explicitly copy/sync them); and also shell access via direct docker exec instead of using ssh?

  11. Roman says:

    Any plans to implement CPP-154? Reported 5 years ago…

    • Anastasia Kazakova says:

      Nice and useful addition indeed. Thanks for reminding about it. Let us consider and see if we can fit it into some upcoming roadmap.

  12. Pipo says:

    I have the following issue in Android Studio that I think is related to Clion’s CMake support: If my CMakeLists.txt (and thus all of my cpp files) are located outside of a module:
    ./Root/Project->Module
    ./Root/Sources/CppSources
    The code inspections turn everything red. I should check if there is similar issue in Clion. Can that be fixed?

    • Anastasia Kazakova says:

      CLion expects project sources to the located in the Project Root directory. Project Root by default is a folder with the top-level CMakeLists.txt files. You can change it in Tools | CMake | Change project root in CLion. AS however supports only the Android C++ projects, not the general CMake projects, so additional issues might be possible.

      • Pipo says:

        After further investigation I concluded that this issue might be gradle/AS only.
        Anyway CLion shouldn’t assume that all project sources are in the same source root directory. The use case I see is if you have external libraries (maybe even shared between projects) that you don’t want to be part of your project but still be available for viewing/editing.

  13. HGH says:

    Can we have mouse zoom level be remembered between sessions? Even better when the mouse wheel is used to increase the font size in a tab all other tabs also get the increase font setting and this gets saved between sessions.

  14. David says:

    The remote development support is great, is it possible to bring this to windows-WSL as well? Right now I have to run it under a linux VM.

  15. Andrej says:

    It is a huge difficulty right now to work with CLion on Windows, because of lack of MSVC debugger. For a very long time I’m waiting for this feature, and I’m really disappointed every single release.

    • Anastasia Kazakova says:

      Could you please help us better understanding the case? You are on Windows with windows environment, MSVC, and what’s the build system? CMake? Is it initial or you’ve build it especially to open project in CLion? is your development fully Windows specific or you just use Windows as a development platform?

      • Andrej says:

        Hello, Anastasia! Thanks for the quick reply.

        We’re a team of many people, developing a cross-platform application. Our build system is CMake. On Windows our compiler is MSVC (on Mac it’s clang, so people, whose development platform is Mac, are already happy with CLion). We use pre-built libraries, and our continious integration on Windows is running on MSVC (so there’s no way I can use MinGW as a compiler).

        There’s a working workflow that I found for myself: writing code and building in CLion, and debugging in Visual Studio Code. But it’s such a pain to switch between these 2 IDEs all the time. Using Visual Studio is also not a good option for me, because I switch operation systems very often and it’s not available for other operation systems.

        • Anastasia Kazakova says:

          Thank you. This is very helpful indeed.

          We can’t estimate the task, but the work was already started. The problem is that we have to implement the debugger on our own, as VS debugger is proprietary. We hope we will be able to run some preview in 2018-beginning 2019.

  16. Blazej Floch says:

    Hi Anastasia,
    Can you comments on environment variable expansion in the Cmake: Generation Path-field.

    I am a little confused as the closest to this became ticket:
    https://youtrack.jetbrains.com/issue/CPP-8069

    I believe that is not really what I am looking for. Neither I care if it is saved with the project, nor do I care for “special” variable expansion.

    However we have a dedicated build system that dictates the build paths, but sets them in an environment var. Having to manually copy this relative/absolute path is kind of a pain. I know that this particular system (rez) is quite widely used in the vfx/animation industry, I can’t be the only one struggling.

    If we could just expand environment variables it would be a second to make a clion project compatible, so the build would reuse existing temporary files.

    Is this something I should reflect in a separate issue? I fear that the one mentioned is bigger than my request and will delay a possible easy fix.

    Thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *