CLion starts 2017.3 EAP

Hi everyone,

We are glad to say that the Early Access Program for CLion 2017.3 is now open. The release is scheduled for the end of this year, and there are so many things planned!

CL_20173_EAP_blog

For now, please feel free to download the build and check the new features and enhancements that are already included. Your feedback is very welcome.

Download CLion 2017.3 EAP

This build (173.2099.3) addresses issues in several major areas, including C++ parser and debugger, it also provides better support for unit testing and a more flexible toolchains configuration. Let’s see what’s inside:

Unit testing: easy to run and debug from the gutter

If you use Google Test or Catch framework for unit testing on your project, you may benefit from the built-in test runner in CLion, which provides a progress bar, a tree view of all the tests running, information about the status, duration, and output stream. There is also the ability to easily sort and rerun tests, export/import testing results, and navigate to the test’s sources. This EAP now makes it easier to run tests and review results by adding special test icons to the editor’s left gutter:

test_icons_cut

You can run the tests using these icons. Besides, they show the status of the tests – success or failure, so you always know, when looking through the code of your tests if they failed recently or not:

test_status

Debugger: GDB 8.0

CLion 2017.3 EAP comes with GDB 8.0 bundled. Among other things, this brings fixes to several major issues and inconveniences.

Since bundled GDB is now built with multiarch support, it can be used for remote cross-platform debug in various Linux/Windows and embedded cases. For example, target Linux from the IDE running on Windows. There is no need to find/build another GDB version for this.

Previously, there was a bug with Application output on Windows, which redirected you to a separate console window instead of the default Run window when debugging (CPP-8175). The most critical case here was debugging the unit tests. Updating to GDB v8 helped to fix the bug, so now the output is printed to the default Run window for both, Run and Debug. (Bear in mind, that on Windows, CLion uses bundled GDB when MinGW32 is selected as the toolchain.)

Several other bugs were also addressed, like “LZMA support was disabled at compile time” error and incorrect rvalue references rendering.

C++ language engine improvements

List initialization improvements

We’ve promised a big overhaul in the problematic areas of CLion’s language engine, which parses, resolves and highlights the issues in your code, as well as provides info for the context search, navigation, and refactorings. Following the plan, we’ve started with the list initialization.

This work addresses lots of issues, most of which are linked to CPP-8143. Like for example:

  • some false “no matching constructor” error,
  • some false “too many arguments” and “too few arguments” errors,
  • invalid “parameter type mismatch” error for boost weak pointer initialization,
  • failed resolve for members of auto variables initialized with uniform initialization,
  • false “Invalid initializer” error with C99 union initializers,
  • and many others.

We definitely appreciate your feedback, and your reports on any issues you find (we expect some regressions here due to the massive changes).

Support for __COUNTER__

__COUNTER__ macro is now properly supported in CLion, which means CLion increments its value properly in the language engine and doesn’t show invalid duplicate declaration errors now:

counter_macro

Unique_ptr related issues (GCC7)

In case of using GCC7 one may encounter various issues with unique_ptr. CLion 2017.3 EAP comes with the proper support for it, and thus issues with unique_ptr such as incorrect “parameter type mismatch” and false “applying operator ‘->’ to … instead of a pointer” are now fixed:

unique_ptr

Invert if condition

One very common refactoring pattern is to invert the condition in the if clause and flip the if-else blocks. It can be used, for example, to simplify complex code using multiple nested if statements. CLion now provides a code intention that can do that:

modernize

Other improvements

In case you have include directives inside namespaces, which is a typical case for JUCE library, you will be glad to know that code completion, navigation and refactorings now work correctly for the symbols from such headers:

modernize

Besides, CLion 2017.3 EAP comes with the support for C++11 friend declaration syntax (CPP-3680).

Toolchains

Upd. CLion 2017.3 was released! Checked the final UI and description in the release blog post.

With this EAP we’ve started working on a configurable list of toolchains. When done, it should allow you to use different CMake/debugger or MinGW/Cygwin/Microsoft Visual C++ toolchains for different projects or configurations (ready in this EAP), and conveniently switch compilers, environment settings, etc (not yet ready).

The work has just recently started, but we want to present this current state to you within this EAP build. Let’s look at what is now supported.

In Settings/Preferences | Build, Execution, Deployment | Toolchains you can now add several toolchain configurations in addition to the Default one.

Default toolchain (macOS case):
default_toolchain

Extra toolchain configured:
nondefault_toolchain

For now you can change:

  • CMake
  • Debugger

On Windows this comes with an ability to select the environment – MinGW, Cygwin or Microsoft Visual C++ (keep in mind that MSVC support is still experimental and is available under clion.enable.msvc setting in the Registry):
toolchain_windows

Now, when you have several toolchains configured, you can go to CMake settings under Settings/Preferences | Build, Execution, Deployment | CMake and select different toolchains for different CMake configurations, for example, one toolchain for Debug, another one for Release:
cmake_configurations

Note that currently the CMake configuration should be named differently (CPP-8466).

These CMake configurations are now available for selection in Run/Debug Configurations:
run_debug_config

Besides this, on Windows CLion now works correctly with tools without providing a full path, for example, custom compiler path. The same logic as platform shell is used to find an executable.

That’s it for now! Check the full release notes here. More changes are coming with further EAP builds – stay tuned.

Download CLion 2017.3 EAP

Your CLion Team
The Drive to Develop

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

61 Responses to CLion starts 2017.3 EAP

  1. Anton says:

    Big thanks for this release!

  2. Roman says:

    Can’t believe https://youtrack.jetbrains.com/issue/CPP-6855, biggest usability improvment for me in 2017

  3. Olof says:

    I got this when trying to run some gtests:

    Testing started at 2:27 PM …

    Could not initialize class com.pty4j.unix.PtyHelpers

    Process finished with exit code 0
    Empty test suite.

    • Anastasia Kazakova says:

      Olof, how did you install the EAP? Make sure you used the clean folder, not the previous installation.
      If all is ok, could you maybe share some logs to investigate? idea.log will be fine

  4. Martin Pecka says:

    When I started CLion after the update (through toolbox), it yelled at me that I don’t have any toolchain configured. Shouldn’t there be a default toolchain always present, or at least migrated from the previous version settings?

    • Anastasia Kazakova says:

      Could you please specify which platform are you at? What toolchains were you using previously, what were CMake, compiler, etc. settings you’ve used before?

      We’ve made some changes to the toolchains configuration, so some problems/bugs are possible. That’s why we are rolling them now in EAP. Your help and collaboration here will be appreciated.

  5. LB says:

    I’d really like to see support for ClangD (when it is ready); see:

    https://clang.llvm.org/extra/clangd.html
    https://github.com/chandlerc/llvm-designs/blob/master/ClangService.rst
    https://docs.google.com/document/d/1kNv2jJK0I0JGnxJxU6w5lUOlrIBoecU4fi9d_o5e2-c/edit

    When it comes to C++, Jetbrains should not reinvent the wheel (badly).

    • Anastasia Kazakova says:

      Thanks. We considered this option, but clangd currently has some technical limitations that makes it impossible to use in CLion. However, we’ll keep an eye on it.

    • Roman says:

      I’m closely monitoring Clang-based IDEs and so far no one is comparable to Clion in terms of user experience. Meanwhile Clion already closed most of code parsing issues I had in my code.

      I hoped that C++-based Clang should have better performance (i.e. lower code completion latency). In practice however on a small and mid-sized projects both Clion and Clang perform very well. But for a large projects (Take as example LLVM/Clang source code itself) neither one have acceptable performance.

  6. Anatoly Kalin says:

    Thank you!

  7. HGH says:

    Just as a note: proper language support for the latest standards is more important than such beautifications as “Invert if condition”…

    • HGH says:

      BTW out of curiosity: Do you have that a list somewhere publicly: “big overhaul in the problematic areas of CLion’s language engine”

      • Anastasia Kazakova says:

        We’ll provide more details when publish the corresponding changes. For now, initialization changes are in public EAP build and they are described in the blog post.

    • Anastasia Kazakova says:

      Indeed. However, we have several people in the team and they are responsible for various tasks. Some are responsible for language support, others – for new inspections and rest. But I understand your preferences of course

    • Vadim Peretokin says:

      I find this feature helpful and I’m glad that this was added.

  8. Serinox says:

    I don’t know if anybody else is on macOS (running 10.12.6) and has been having this problem but with this release of CLion it no longer permanently consumes 200% of my cpu when it is open in the background. I can finally use CLion when not plugged in and get a battery life of beyond 45min! This issue had been occurring for me since the start of the 2012.2 eap.

  9. Cedric says:

    Thx for finally fixing the unique_ptr and size_t (MSVC, x64) issues. Had to deal with Dxnoref pointers, knowing they are MyClass pointers…

    Can’t wait for more fixes :)

    • Cedric says:

      Nvm size_t issue didn’t get fixed… still waiting for that one…

      • Anastasia Kazakova says:

        Do you have a link to the issue in tracker, so that we check?

        • Cedric says:

          It’s an issue with CLion not recognizing the MSVC vcruntime.h header x64 types (like __int64 etc.). There are plenty of issue trackers on YouTrack but since there’s no official support for MSVC these issues are left open for centuries (imo).

          Since I’m working with CEF (x64, x86 works completely fine) which only compiles with MSVC (or Ninja), I’m getting many errors in the editor, but the program builds without any errors.

          I’m a huge fan of JetBrains Products (e.g. IntelliJ, WebStorm), but it’s a big disappointment that this product is more or less incomplete. I think by fixing these small issues, rather than adding new features (which I really appreciate), more people would move to this IDE.

          • Anastasia Kazakova says:

            Indeed MSVC-specific headers are not yet parsed correctly sometimes, we are working on it and not making MSVC support enabled by default exactly because of these issues. Thanks for pinging

  10. Matthias says:

    I am disappointed to see that the bundled LLDB is still 3.9. Is the upgrade to 4.0 or 5.0 still planned for 2017.3 – see https://blog.jetbrains.com/clion/2017/07/clion-2017-3-roadmap/#roadmap?

    • Anastasia Kazakova says:

      We do consider upgrading the bundled LLDB. Not sure about the estimation. Which platform are you at btw?

      • Matthias says:

        I am on OS X. There were a few useful improvements in the LLDB data formatters since 3.9 which would my life a lot easier, which is why I was looking forward to 2017.3.

  11. John says:

    Any chance some Doxygen improvements will make it into 2017.3? These are pretty small, but I think they can have a big impact on large code bases and affect C and C++ projects alike.

    Color parameter names in Doxygen comments
    https://youtrack.jetbrains.com/issue/CPP-10311

    Highlight incorrect Doxygen parameter names
    https://youtrack.jetbrains.com/issue/CPP-9282

    Markdown formatting in Doxygen comments
    https://youtrack.jetbrains.com/issue/CPP-8590

    • Anastasia Kazakova says:

      Thanks, we’ll consider these improvements. If we have enough resources for this on this iteration, we may take a look. But I can’t promise you anything.

  12. Tano says:

    Hello Anastasia, 2 questions:
    1. When will 2017.3 final be released?
    2. Will this fix be included? https://youtrack.jetbrains.com/issue/CPP-4519

    Thanks

  13. Sven says:

    Hello, I have a question regarding “Multiple toolchains support”:
    – Will it be possible to specify GNU ARM Embedded Toolchain?
    – And will it be possible to use SDCC (Small Device C Compiler)?

    Thanks

    • Anastasia Kazakova says:

      CLion currently supports GCC- or Clang- based compilers, MSVC in the experimental mode, and also Intel can be used. So GNU Arm Embedded Toolchain fits the requirements. Regarding the SDCC, it doesn’t support ‘-dM -E -x c /dev/null’ to get compiler predefined macros, so won’t work in CLion.

      Anyway, the question doesn’t relate to the latest changes. You can change compiler in the oldest versions as well.

  14. tehort says:

    Any news about the MSVC debugger implementation?

  15. Jennifer Kuiper says:

    Hi Anastasia,

    Kudos for what you guys have achieved sofar. Would you be able to disclose when more C++17 features will be included, such as Structured Bindings?

    Kind regards,
    Jennifer

    • Anastasia Kazakova says:

      Thanks, Jennifer.
      We’d like first to finalize the big parser overhaul that’s currently in progress and then start more C++17 features. You can track the progress for structured bindings here: https://youtrack.jetbrains.com/issue/CPP-8261. Unfortunately, that’s unlikely they are coming to 2017.3

      • Jennifer Kuiper says:

        Hi Anastasia,
        While I do appreciate all the work that is put in to improve the IDE, I do feel that language features are at least as important. As C++17 can be selected as a target in the IDE, I realize that very few C++17 features have been implemented. :(

  16. hey guys, now debugger evaluators work for all stl containers, clang toolset, osx 10.13.1, xcode 9.0.1 (9A1004). this is fantastic, do not need to use xcode anymore. cool work, thanks clion team

    • Anastasia Kazakova says:

      Thanks for your feedback!

    • Yaroslav Gamayunov says:

      Hi !
      I’m new at Clion. I tried to make it work, but debugger doesn’t show elements of some stl containers (set for example). Could you tell me how did you make it work?

      • Anastasia Kazakova says:

        Could you please tell what is your platform and debugger? What is your CLion version and if you use the bundled debugger or a custom one?

  17. Dimiter Stanev says:

    Thanks for the update! I’m using CLion for my home projects, (+Rider at work for some on #), but heavy Resharper C++ user (work/home). (Also YouTrack user at work too – you do have some awesome projects!).

    So I’m just wondering, how close are the technologies for parsing/editing/analyzing C++ between CLion + Resharper C++ – e.g. are they usually on parity when comes to features, or are they developed independently. Just curious, as both are very close in achieving very good C++ editor capabilities.

    I guess at some point I might have to move to CLion (even at work, but not sure yet how) as MSVC IDE is still 32-bit, ReSharper is in it (along with other plugins) and sometimes I hit 1.8GB of RAM used (out of 3..3.5GB?), while CLion being fully 64-bit won’t have such limitations.

    Thanks!

    • Anastasia Kazakova says:

      CLion and ReSharper C++ have two different parsing solutions. Mostly this happens because the ReSharper and IntelliJ- platform architectures are very different. However, while we do test different approaches and ideas in these two teams, we collaborate and talk often to share the winning strategies which bring better user experience. We also try to align the IDE’s roadmaps and features.

Leave a Reply

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