CLion 1.5 EAP: build with variadic templates support


Today we have an experimental CLion 1.5 EAP build for you to try. In the roadmap for version 1.5 we’ve promised to work on support for variadic templates. We’ve spent awhile working on it, and now this build (144.3891) does provide support for variadic templates, as well as fixes for many related issues.

Before we go into details, let’s explain why we call the build experimental. This means we can’t guarantee now that all the provided changes and fixes will make their way to the final CLion 1.5 release. We’d like to be sure that the quality of the support and the performance is sufficient. If not, we’ll keep on working on this and deliver the fixes as soon as they are ready.

As we’ve said above, this build provides support for variadic templates, especially fixing many problems in overload resolution. That means the code should be resolved correctly and code analysis doesn’t show ‘false positives’ on such code constructs, like for example ‘Function recurses infinitely’ for the variadics with termination call:

Qt users will find a significant progress in resolve, since Qt C++11 connect calls are now resolved correctly as a result of the variadic templates support:

Find the list of issues fixed by the variadic templates support in our tracker.

We encourage you to try the build (a patch update will also be available soon), especially in case you are working on a project with vast usage of variadic templates. Please report any issues with parsing/resolve to our tracker, as well as take note of the IDE performance. If you feel it’s gotten worse (compared to the previous EAP build, for example), then please share snapshots and logs with us.

Some other fixes this build also delivers:

  • We continue our work on debugger, and now when debugger reports an error during the evaluation or variable collection, it is reported in UI. This could improve stepping performance and possibly reduce the number of ‘timed out’ errors.
  • ‘Include parent environment’ option in Run Configurations is now ‘on’ by default (CPP-5453).

Full release notes are available by the link.

And on the new Preview Next Version page on site you can find the details about all the new features currently making their way to CLion v1.5.

The CLion Team
The Drive to Develop

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

36 Responses to CLion 1.5 EAP: build with variadic templates support

  1. Olof says:

    I haven’t tried this EAP (I’m running 3600 using an external Java8), but as a general note about performance since you mentioned it I avoid using most of the refactoring tools. In my project it can sometimes lock up the API for minutes, or long enough that I kill and restart.

    I also experience intermittent lockups that I can’t track down to a particular action. These vary from seconds to long enough that I assume the system has locked up and I kill and restart.

    I’m experimenting with running with power save mode to see if that helps.

    This is on 32 core server hardware with SSD drives.

    Unfortunately I can’t share many details about my project setup. I’d be happy if there were some guidelines for how to either troubleshoot the GUI performance or maybe CMake constructs to avoid. I wouldn’t be surprised if we are just using some particular CMake construct that has some issue.

    I still prefer CLion over the alternatives, so keep up the good work. :)

    • Anastasia Kazakova says:

      Thanks for your support!

      Especially for the UI lock ups, and other performance problems, CPU snapshots could be very useful for us to investigate the problems. Could you please make some ( and share with our support via submitting a request?

      • Olof says:

        We are very sensitive with regards to IP. What information would it contain? Would it be small enough and legible enough that I can read through to guarantee no information leakage?

        Here’s one piece of information though which I hope might be helpful. It takes about 5 minutes to reload the cmake file. The progress bar at the bottom moves quickly to full, then it gets stuck at “Updating symbols…” with the little spinner. The spinner animates for a little bit and then that’s where it gets stuck for many minutes. During this time the cpu is stuck at around 140% – 160% CPU. Then it wakes up and checks incoming and outgoing VCS changes. That goes pretty fast. After it completes that CPU goes up several hundred percent and tops out at around 1000%. The box is otherwise idle during this.

        The same cmake file generates an Eclipse project in a second or two.

        This is with 3600, and it feels as if it has gotten slower lately. The last production release I used was 1.2.2.

        • Anastasia Kazakova says:

          CPU snapshot will contain only IDE’s internal calls/methods.
          You can download the demo version of the yourkit and check the snapshot doesn’t contain your sensitive data.

          • Olof says:

            I did a snapshot but looking through it I don’t think I could send it. :(

            Let me know if there is another way I can help track down this problem.

          • Anastasia Kazakova says:

            You could try collect thread dumps ( and IDE logs and submit them to our support. Will that work?

          • Olof says:

            I’ll look into that.

            In the mean time, I do see this alert when I reload CMake file:

            “Do not call synchronous refresh under read lock (except from EDT) – this will cause a deadlock if there are any events to fire.”

            And then I’m stuck with the “0 Updating Symbols” and an almost full progress bar” for a while.

            Maybe it deadlocks and you have a deadlock timeout thing?

          • Olof says:

            Better info:

            [495014809] ERROR – pi.vfs.newvfs.RefreshQueueImpl – Last Action: CMake.ReloadCMakeProject
            [495016390] ERROR – pi.vfs.newvfs.RefreshQueueImpl – Do not call synchronous refresh under read lock (except from EDT) – this will cause a deadlock if there are any events to fire.
            at com.intellij.openapi.diagnostic.Logger.error(
            at com.intellij.openapi.vfs.newvfs.RefreshQueueImpl.execute(
            at com.intellij.openapi.vfs.newvfs.RefreshSessionImpl.launch(
            at com.intellij.openapi.vfs.newvfs.RefreshQueueImpl.processSingleEvent(
            at com.intellij.openapi.vfs.newvfs.impl.VirtualDirectoryImpl.a(
            at com.intellij.openapi.vfs.newvfs.impl.VirtualDirectoryImpl.a(
            at com.intellij.openapi.vfs.newvfs.impl.VirtualDirectoryImpl.refreshAndFindChild(
            at com.intellij.openapi.vfs.newvfs.VfsImplUtil.refreshAndFindFileByPath(
            at com.intellij.openapi.vfs.impl.local.LocalFileSystemBase.refreshAndFindFileByPath(
            at com.jetbrains.cidr.lang.symbols.symtable.FileSymbolTableSerializer$
            at com.jetbrains.cidr.lang.symbols.symtable.FileSymbolTableSerializer$
            at com.esotericsoftware.kryo.Kryo.readClassAndObject(
            at com.esotericsoftware.kryo.Kryo.readObject(
            at com.esotericsoftware.kryo.Kryo.readClassAndObject(
            at com.esotericsoftware.kryo.Kryo.readObject(
            at com.jetbrains.cidr.lang.symbols.symtable.FileSymbolTablesPack$
            at com.jetbrains.cidr.lang.symbols.symtable.FileSymbolTablesPack$
            at com.esotericsoftware.kryo.Kryo.readObject(
            at com.jetbrains.cidr.lang.symbols.symtable.FileSymbolTableSerializer.readSymbolTables(
            at com.jetbrains.cidr.lang.symbols.symtable.FileSymbolTablesCache.a(
            at com.jetbrains.cidr.lang.symbols.symtable.FileSymbolTablesCache.access$2100(
            at com.jetbrains.cidr.lang.symbols.symtable.FileSymbolTablesCache$10$1.compute(
            at com.jetbrains.cidr.lang.symbols.symtable.FileSymbolTablesCache$10$1.compute(
            at com.intellij.openapi.application.impl.ApplicationImpl.runReadAction(
            at com.jetbrains.cidr.lang.symbols.symtable.FileSymbolTablesCache$10.consume(
            at com.jetbrains.cidr.lang.symbols.symtable.FileSymbolTablesCache$10.consume(
            at com.jetbrains.cidr.lang.symbols.symtable.FileSymbolTablesCache$
            at com.intellij.openapi.application.impl.ApplicationImpl$
            at java.util.concurrent.Executors$ Source)
            at Source)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor$ Source)
            at Source)
            [495016395] ERROR – pi.vfs.newvfs.RefreshQueueImpl – CLion CL-144.3600.8 Build #CL-144.3600.8
            [495016396] ERROR – pi.vfs.newvfs.RefreshQueueImpl – JDK: 1.8.0_71
            [495016396] ERROR – pi.vfs.newvfs.RefreshQueueImpl – VM: Java HotSpot(TM) 64-Bit Server VM
            [495016396] ERROR – pi.vfs.newvfs.RefreshQueueImpl – Vendor: Oracle Corporation
            [495016396] ERROR – pi.vfs.newvfs.RefreshQueueImpl – OS: Linux
            [495016396] ERROR – pi.vfs.newvfs.RefreshQueueImpl – Last Action: CMake.ReloadCMakeProject

          • Anastasia Kazakova says:

            Could you please try the latest EAP, just published. And please check if Invalidate Caches and Restart helps.

          • Olof says:

            OK, will try.

            Don’t know where the “lBPH6mQx” came from.

          • Olof says:

            With that new build I no longer get that exception and the cmake file loads faster, but it still takes a minute or two.

            This wouldn’t be such a big deal except whenever I add a .cpp file I have to reload the cmake files for the entire project to get the .cpp file into the project.

            file( GLOB_RECURSE SOURCEFILES “*.cpp” “*.h”)

            Maybe that’s the reason but I don’t think I can change that.

            Or at least, that’s the only way I know how to do it.

            Is there another way I can do this?

          • Anastasia Kazakova says:

            Have you compared the time with cmake command running from the terminal (without CLion)? Is it the same more or less or differs?
            Besides, GLOB is not recommended by cmake itself –

          • Olof says:

            I should have said “We use file(GLOB…”

          • Olof Edlund says:

            Man, it is easy to respond to the wrong post here.

            Yeah, a second or two to generate an Eclipse project and a make file structure.

        • Olof Edlund says:

          Yeah, it takes about a second or two from the command line to generate an eclipse project and a make file structure.

          I’ll read the link you provided though.

          • Anastasia Kazakova says:

            We are actually executing CMake on prj reload in the way like:

            cmake -DCMAKE_BUILD_TYPE= -D CMAKE_C_COMPILER=/usr/bin/gcc -D CMAKE_CXX_COMPILER=/usr/bin/g++ -DCMAKE_BUILD_TYPE=Release -DCMAKE_ARCHIVE_OUTPUT_DIRECTORY=/Users/anastasiakazakova/prj/Counters/bin/Release -DCMAKE_LIBRARY_OUTPUT_DIRECTORY=/Users/anastasiakazakova/prj/Counters/bin/Release -DCMAKE_RUNTIME_OUTPUT_DIRECTORY=/Users/anastasiakazakova/prj/Counters/bin/Release -G “CodeBlocks – Unix Makefiles” /Users/anastasiakazakova/prj/Counters

            You can measure this command execution on your project running the command from the terminal.
            That’s all what is done in CLion on cmake reload. So mostly it’s the time for cmake command working by itself.

          • Olof says:

            Per CLions reporting, it is the Updating Indices -> Updating Symbols that takes a long time. Reloading the CMake takes about 5 seconds which would be consistent with it taking about one second on the command line if you do it four times.

      • Olof says:

        I’ll add one more thing. I tried to restart to see how that performs. The loading of the cmake file at that time from the moment the progress bar at the bottom starts working and says loading the CMake project until it is done takes about 30 seconds.

  2. Marcus says:

    I’ve just tried the new version and I no longer get false positives at some points that I used to get them – however, I still get false positives absolutely everywhere in my project. (the file I’m currently working on; 226 lines long, CLion says there are 144 errors, clang with -wall compiles with no warnings or errors – random other file; 209 lines long CLion; 25 false positives)

    Various things are causing all these (all reported in your bug database)

    If I ever dare to use one particular lambda template that has the form SomeTemplate CLion gets totally broken and almost the entire file is failed to parse.

    Other things are broken with the parser too (also in your bug database) – most annoyingly, if I pre-declare a class then this is the point that the cursor is taken to when I CTRL-click (so I have to use a textual “Find in path” like in the old MS-DOS days)

    I really want to like CLion (and hoped that it would be a C++ version of IDEA) but this parser is just nowhere near good enough; I dream of the day when you guys switch to the clang parser and turn CLion into the product that it deserves to be.


    • Anastasia Kazakova says:

      Hi Marcus,

      Could you please share the tickets link? We’ll recheck. Is the template problem also there?

      Regarding the libclang, we’d like to rely on it, but there is a bunch of reasons it’s not possible for now. We tried to describe them in this blog post – – C++ parser section.

      • Marcus says:

        Re; the clang parser thing.

        Well, of course, it’s up to you how you implement things. I know that the KDevelop team did some work with the clang tooling people when they made clang its default parser for the upcoming KDevelop 5 (and that work is in the upcoming clang 3.8 release) – it may be worth another look now.

        Re; the parser problems that plague me

        I would say that about 80% of the false positives that I have relate to;
        CPP-4987, CPP-4957 and CPP-5842

        In code that does SIMD things then I get quite a lot of CPP-790 trouble.

        The other 20% of parse errors are various different things (that I ran out of time to dig out of your bug database)

        As for usability; Two things that I use all the time “Go to related symbol” and CTRL-click to a type frequently fail to work;
        CTRL-click with often go to a pre-declared version of the type
        “Go to Related symbol” will often hang for ages and then not do anything

        Don’t think that I have a negative view towards CLion; many things that it does are very clever and way better than other IDEs – right now though, I’m muddling through using CLion because I’m such an optimist.


  3. Marcus says:

    previous comment didn’t get escaped; the lambda template form should read;


  4. Peter says:

    Nice, make_shared and make_unique no longer show false errors.

    • Anastasia Kazakova says:

      Great. Thanks for sharing.

      • Yury V. Zaytsev says:

        Yeah, at least smart pointers are not red anymore, but anything more complicated is still broken :-/ Reported as CPP-5850 Variadic templates inside namespaces: infinite recusrion, wrong number of arguments, feel free to link with other tickets if appropriate.

  5. Martin Pecka says:

    The release notes state “IDEA-69424 Ubuntu global menu integration” as implemented. It’s not been working for me on Ubuntu 14.04, even after manual installation of jayatana.

    • Anastasia Kazakova says:

      Could you please leave a comment in this issue – we’ll have a look, probably will ask you for some additional details.

  6. Ivan says:

    I have been trying to use Clion for several months now but it has a serious bug in the debugger. It takes several minutes on an i7 Sandybridge CPU to start the debugger. During this time, gdb uses uses a single thread and stays stuck for several tens of minutes. After that, the debugger works without issue. You can test this bug out in this open-source project:

    Going to PROJECT_ROOT/gtsam/base/tests/testCholesky.cpp
    and setting a breakpoint on the first line of the first test should reproduce this bug.

    Since this is a heavily templated project it takes a very long time to build/update symbols especially since I am frequently switching git branches. Is there any way to limit the number of CPU’s Clion uses to build symbols to avoid choking my system so I can continue using the IDE while it’s doing the background tasks?

    Even with all of this you guys are still the best IDE out there so keep it up!

  7. Paolo says:

    Hi guys, great work as usual.
    Just a note: taking as reference your first example, if I declare func() {} after and not before func(T head, Tail… tail), code doesn’t compile, reporting “no matching function for call to func” when func(args…) is invoked.
    Same code compiles properly on VS2015

Leave a Reply

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