CLion 2017.3 Release Candidate

CLion 2017.3 release is just around the corner! And today we are glad to announce CLion 2017.3 Release Candidate (build 173.3727.18). We encourage you to try the build and kindly ask you to share your feedback and comments with us and report any bug at all to our tracker.

This build addresses the following issues:

  • 2017.3 EAP brought Valgrind Memcheck integration into CLion. This build improves the UI by placing the frame information and the code preview in different tabs:
  • False ambiguous error on tuple initialization was fixed (CPP-10995).
  • Clang-Tidy integration was not working properly in case of Cyrillic symbols in the files.

The full list of fixes and improvements is available here. Note, that this build doesn’t require an active subscription.

Download CLion 2017.3 RC

Your CLion Team
The Drive to Develop

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

41 Responses to CLion 2017.3 Release Candidate

  1. Olof says:

    I thought that major improvements to correctness and performance was scheduled for this release.

    Did I miss them or did they not make it.

    • Tano says:

      Performance is a big big problem with CLion (CPP-11121 and CPP-9913) and really must be fixed before this visual “nice to have” things.

      • Marcus says:

        And before “Performance”, how about some “Correctness” in that parser?

        Now that clangd is getting off the ground, I feel that a world of other editors will soon have 100% correct C++ parsing through the Language Server Protocol – CLion’s window of opportunity is running short.

        Such a shame, as I’d always dreamed of an IntelliJ for C++.

        • Tano says:

          I think c++ parsing is 10 times harder than java.

          • Marcus says:

            Oh, I’d agree with that!! Just look at the size of the language specification!

            This is why many people were suggesting that Jetbrains look into using the clang parse engine last year – not only does it work now but it’ll track the new features added to C++ (ie C++17) – it’s even BSD licensed :/

        • Roman says:

          Honestly, can you name any other IDE for Linux that is better than Clion? I’ve tried them all and IMO nothing is comparable to Clion for CMake-based projects. Clion has some glitches, but everything else is much worse.
          The problem is that Clion competitors has much less resources than JetBrains, so they can’t compete. Development of Eclipse, Netbeans, QtCreator etc is really slow comparing to speed of changes in Clion.
          Only Microsoft is comparable, but it is not clear if they are willing to invest a lot of engineers into making VSCode a true IDE. Visual Studio for Windows seems to be their priority.

          • Marcus says:

            I’d agree that CLion is the best option at the moment – but only really because the others are so lacking. My point was that with clangd this will shortly change.

            Even with the clangd in the 5.0 release (which could be considered super early alpha) VSCode, Atom and Sublime get a free C++ parser/linter that handles all C++17

            Once clangd gets a proper release, people will have the option;
            – an IDE with less features, but they all 100% work
            – CLion with more features, but they are all unreliable

            what use is “Find uses” to me when a dodgy parser means that it’ll miss loads of call sites.
            how about “goto definition” that unhelpfully takes you to a forward declaration rather than the actual definition; or, takes you nowhere at all.
            “next error” and the “error/problem” view are useless as there are dozens of false positives.
            even “switch header/definition” frequently hangs (or takes you to some random file)

            I’ve used IntelliJ a lot in the past and know just how good Jetbrains stuff can be; it makes all this so frustrating!

          • Roman says:

            So basically it is a pure speculation now. We are trying to compare Clion with some IDE from future that does not exist yet :)
            Personally I also have a high hopes on clangd, but currently it is hard to say how fast it will evolve. Afaik, currently it does not even have some basic code generation and refactoring capabilities, like “generate definition” or “rename”.

        • Tano says:

          I agree with you, CLion is the best at the moment but it frustrates me that it lacks some very basic things that all other IDEs have, like support for “make install”(asked 2-3 years ago) or to be a bit faster (on files with 3000+ lines it works very very slow)

          And it seems that sometimes JetBrains makes some very complicated and innovative(perhaps unnecessary) stuff but they lack on basic ones…

          • Emil says:

            I also miss the make install support.
            My workaround is to add a normal cmake target that calls make install.
            It works, but clutter the number of available targets.

          • Anastasia Kazakova says:

            I know make install would be very helpful. We’ll try to see if we can fit it next release.

    • Anastasia Kazakova says:

      Let me address your question.

      2017.3 included two big parser overhauls: initializer lists and name lookup. That cleaned up many false-positives in the CLion’s analyzer and made the experience on many projects better.

      Performance was also addressed with some fixes. Maybe not that many, as we planned to, but still.

      • Olof says:

        To be perfectly honest I would vote for a feature freeze for the next road map as a strong arm manager move to right the course and that all effort would go towards parser correctness and performance.

        I understand that you have different competencies and experts in different areas. But the wrong resource is better than no resource, And the wrong resource becomes that right resource over time.

        But to me this is a little bit of a lost quarter. There is no feature delivered that I really care about and the biggest problem is still performance and correctness.

        I used to be an evangelist for CLion where I work. My reasoning is “It’s the resharper company”. But parser correctness and performance can only be the biggest problem for so long until I no longer can use that argument.

        To be clear, I want CLion to succeed.

        Maybe you should get input from your users?

        • Tano says:

          I again agree with Olof, the speed is really terrible.

          “Performance was also addressed with some fixes. Maybe not that many, as we planned to, but still.”
          Please note that in 2017, CLion is unable of handling files bigger than 2000 lines. After 2000 lines the typing is lagging a lot…
          But we got Kotlin and JUCE support, great!;)

          5 of my colleagues tried CLion and after the free month, all of them returned to Eclipse/NetBeans/vim because of speed and the lack of basic features. A lot of users ask for memory view in Debug for 2 years and nothing happens. Please note that the memory view exist in IDEs for 10 years.

          I also want to CLion to succeed, cause in january I will renew my license 😀

        • Anastasia Kazakova says:

          Thank you Olof. We are dedicating as much resources to the parser-related issues as possible. You are that there are people in the team who are responsible for other parts. And I strongly believe these areas are important. For example, they are users who are happy with the parser but suffer from debugger’s issues. So we do our best to cover all critical areas, postponing those tickets that indeed have lower priority.

          As I’ve already said, we’ve started the big overhaul in parser that should lead to many improvements. List initialization and name lookup were part of the plan. And we’ll continue with these overhauls in further versions. Luckily, we recently got more people for C++ language support area, so the speed will increase hopefully.

  2. raver119 says:

    Bells and whistles aren’t that important when IDE freezes, or takes full 3 cores while editing some file…

    • Anastasia Kazakova says:

      If you experience any issues like that, have you submitted thread dumps and CPU snapshots to us to investigate?

      • Victor Sergienko says:

        I do have a heavy performance problems too. I have submitted a bug (CPP-10781) with a CPU profiles of 2017.3 and, on Anna’s request, for 2017.2, which was much better.

        Rolled back to 2017.2 for now, its code analysis was much faster.

  3. Olof says:

    It seems that I no longer can stop builds.

  4. beimingkun says:

    Yes, I also agree the most wanted thing for me is correctness and performance. But to be honest, I will stick to CLion at least for a while, since it seems to be the best C++ IDE for my project.

  5. Eduard Maximovich says:

    Guys! Who have a performance issues, and if you are using cppcheck plugin, try to disable it, something wrong with cppcheck or with plugin i don’t know, but it uses cpu at 100% after any code change.

  6. Tano says:

    I have a question please, not related to this release: how do I disable a specific warning in clang-tidy? For example I want to disable “modernize-use-auto”, it seems to be default “on” in CLion but I cannot find it.

    • Pete says:

      Take a look into Settings->Editor->Inspections->C/C++ ->General->Clang-Tidy. There you can set the Clang-Tidy options cmd line.

    • Anastasia Kazakova says:

      You can disable in Settings | Editor | Inspections | C/C++ | General | Clang-Tidy, there is a text-form field with Clang-Tidy settings.

      • Tano says:

        Yes, I know the options but, although “modernize-use-auto” is not present there, clang-tidy suggests “auto”. And also, on the CLion page says that it’s enabled by default, therefore I guess that CLion adds secretly this option and cannot be changed?
        Should I report this as a bug?

  7. KB says:

    Clion is a performance pig and the will never be able to keep up with advancements in the C++ language ans STL. Ditch the existing parser and dedicate resources to clang.

    • Anastasia Kazakova says:

      Performance problems are related to parser, but are not solvable by just switching the parsing engine. clang will have same issues if just plugged into current solution. We are working constantly on performance improvements and also plan a big overhaul in this area for 2018.1 ( If you can, please, share the CPU snapshots from your particular performance issues with CLion, we’ll analyze and see if that’s smth new to us or maybe one of the problem that we plan to address in 2018.1. Thanks in advance.

      As for the clang solution as parsing engine, mind, that it’s still not suitable for refactorings and other per-project actions (not per TU), as symbols cache is absent. However, we constantly analyze clang solution to check if it can be beneficial for us.

Leave a Reply

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