CLion 2017.3 EAP: C++ language engine improvements and build type switcher

Hi,

A new CLion 2017.3 EAP build (173.3531.13) is now available for download.

Previous EAP build brought Valgrind Memcheck integration to CLion. And now we are back to the C++ language support improvements. Check them out and let us know if any error occurs, especially if you see any regression (in comparison to the stable version).

Download CLion 2017.3 EAP

C++ language engine improvements

Our recent plan for C++ language engine was to start from the bottom and work our way up to the top, implementing big overhauls in the problematic areas of our parser. 2017.3 EAP has already brought list initialization fixes. And now it’s time to roll out name lookup improvements. Some issues that were fixed by these changes:

  • Class inheritance didn’t bring symbol into scope (CPP-8399)
  • Namespace alias was not looked up in if conditions (CPP-7279)
  • Type resolution failed in case of typedef referring to a symbol imported via using (CPP-9960)
  • Incorrect resolve order of the declarations (CPP-10717)
  • Other issues with using, the order of declarations, etc.

Debug/Release switcher

During this release cycle we’ve improved the toolchains support and made the configuration process clearer and more flexible. CLion now allows to configure and use several toolchains (i.e. CMake, compiler, debugger set) and link them to the appropriate CMake Profile.

To use necessary CMake Profile during Running/Debugging your app, you previously had to create several Run/Debug configurations with different CMake profiles. Now you can simply select necessary CMake Profile in the run configuration switcher on the toolbar:
run_debug_switcher
or in the Run/Debug configuration switcher popup that opens via Shift+Alt+F10 (Linux/Windows) / ^⌥R (macOS) for Run and via Shift+Alt+F9 (Linux/Windows) / ^⌥D (macOS) for Debug:
run_debug_popup

A couple of important notes:

  • Resolve context in the editor is updated automatically when the CMake profile is changed.
  • When running/debugging tests via automatically created Run/Debug configuration,
    the currently selected CMake Profile is used.

The list of all changes is available here.

CLion 2017.3 EAP: quick overview

Here is a quick reminder of the changes we’ve already made to CLion 2017.3 EAP:

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.

29 Responses to CLion 2017.3 EAP: C++ language engine improvements and build type switcher

  1. Catskul says:

    Glad to see so much focus on bug fixes and performance!

    Can we get some attention on this “search everywhere” focus bug? https://youtrack.jetbrains.com/issue/IDEA-124160#tab=History&u=1509357001707 ?

    There are ~140 votes and several come in every day. It completely destroys productivity.

  2. Cyr Sap says:

    Debug/Release switcher is great but CPP-11064 is still present

    • Anastasia Kazakova says:

      Seems we need some additional data to understand the case better (can’t reproduce it here). Let’s proceed in the tracker.

  3. Yaroslav says:

    > To use necessary CMake Profile during Running/Debugging your app, you previously had to create several Run/Debug configurations with different CMake profiles …

    I understand the reason for decoupling cmake profile from a build configuration.
    But the build configuration also has another options (command line arguments, post-build actions, environment). And this options might my coupled with a certain cmake config. So I cannot now merge my debug|relese build configs and just switch the CMake profile. It is necessary now to switch both build conf. and cmake profile synchronously.

    Possible solution would be not to remove cmake profile option from the build config but add additional option “Current CMake Profile”. It allows both to use selected cmake profile or to specify one directly. So build config is able to force switching cmake profile.

    Also if cmake profile is decoupled from the build config, there is needed a $CMakeProfile$ placeholder which is expanding in all optoin fields of build config. ($$ placeholders)

    • Anastasia Kazakova says:

      But build type is a part of CMake profile. And if you need several CMake profiles with one build type, you can create them. In the switcher in the navigation bar the list of CMake profiles will be shown.

      • Yaroslav says:

        Saying “build config” I meant run configuration (RC)
        I already have several cmake profiles. Also I have several several RC.
        In each RC appropriate CMake profile was specified. Now this option is gone. So each time I change RC it is necessary to not forget to choose an appropriate CMake profile.

  4. Yaroslav says:

    > Our recent plan for C++ language engine was to start from the bottom and work our way up to the top, implementing big overhauls in the problematic areas of our parser.

    Cool, and do not forget please the very “bottom” feature which all other c++ IDEs already have – parse and resolve references inside macro.

    https://youtrack.jetbrains.com/issue/CPP-6544
    https://youtrack.jetbrains.com/issue/CPP-10170

    • Anastasia Kazakova says:

      Bottom to top – mean the layers of our parser/resolver. So name lookup is essentially at the very bottom of this stack. That’s why we’ve started with it.

      Full and correct parsing and resolve inside macro is a very tricky task, we might consider however some solution covering most used cases (like Eclipse does, etc.)

  5. MArcus says:

    This is a nice version – now I have some source files that have zero false parse errors!

    I am really glad that you’re back on the parser – it gives me some hope for CLion.

    Marcus.

  6. Jan Möller says:

    Yay, thanks for the build type switcher, I was waiting for this :) And there are less parsing errors with every build, so that makes me happy as well. Keep going!

  7. Tano says:

    Anastasia, is there any chance to add a greater support for “install”?
    https://youtrack.jetbrains.com/issue/CPP-838
    I managed it to “trick” somehow by adding “install” to build options, but the output is incorrectly shown (https://youtrack.jetbrains.com/issue/CPP-9530)

    Using this trick Eclipse and Netbeans show it properly, CLion does not.:(
    Thank you

    • Anastasia Kazakova says:

      We keep an eye on it, but it’s still not in the shortlist. We’ll see if we can prioritize it above some others.

      • Tano says:

        Great, perhaps it will be included in 2018, because “make install” is such a basic feature of Linux… and CLion does not properly support it. The only solution is to modify the CMake to “install” but other non-CLion work colleagues will not appreciate it.:)
        Thanks a lot!:)

  8. Matt Hurd says:

    +1 for structured binding support, pretty please

  9. Tano says:

    Also please small but disturbing things like this one:
    https://youtrack.jetbrains.com/issue/IDEA-172930
    Path field 10000 pixels, file mask 10 pixels.
    Just resize them please until you find a proper solution.
    Thanks.

  10. Mustafa says:

    Folks,

    Does 2017-3 support structured bindings ? I’m testing with 2017-2. it compiles but clion show everything inside [] as undefined.

    Another issue I’m not sure is it bug or not but for unique_ptr

    unique_ptr m;
    m->lock(); // compiles but UI show false positive
    (*m)->lock(); // Clion doesn’t complain

    Kind Regards,
    Mustafa

    • Anastasia Kazakova says:

      Unique_ptr has been fixed in 2017.3. structured bindings are planned for the next release, but 2017.3 make the code analysis in this case still better. Have you tried the RC2 build?

Leave a Reply

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