CLion 2019.1 Release Candidate is Here

Anastasia Kazakova


Please welcome the Release Candidate for the upcoming CLion 2019.1!

Download the build 191.6183.49 from our website, update from the Toolbox App, or through a snap package (if you are using Ubuntu).


Please note that to use CLion 2019.1 RC, you need to have an active subscription (or start a 30-day evaluation period). No patches are provided for this release candidate, but you can expect a patch from the latest 2018.3.4 update to the 2019.1 release version.

Resync with Remote Hosts

In the full remote development mode, the CLion instance runs locally and synchronizes header search paths from the remote machine to the local host (to resolve the code correctly in CLion). Previously, we’ve triggered the synchronization of the header search paths on every CMake reload, which might be a time-consuming task. Now the resync is performed only when triggered manually, by calling Tools | Resync with Remote Hosts.
The registry option clion.remote.resync.system.cache allows you to change the behavior to the previous one, if you still prefer it.

Besides that, this RC delivers the following fixes and changes:

  • Clangd memory indicator is now turned off by default and can be enabled along with the JVM memory indicator in Settings/Preferences | Appearance & Behavior | Appearance | Windows Options | Show memory indicator.
  • When MinGW is used in CLion, user input is no longer duplicated in the output window (CPP-2580). Unfortunately, the issue is still present for WSL and Remote toolchain cases (CPP-15753).

The full release notes are available here.

Your CLion Team
The Drive to Develop

Comments below can no longer be edited.

13 Responses to CLion 2019.1 Release Candidate is Here

  1. Andrei says:

    March 20, 2019

    “Clangd memory indicator is now turned off by default ”
    What is the reasoning behind this I wonder…

    • Hannes Steffenhagen says:

      March 20, 2019

      It was only meant for debugging the EAP/finding out if clangd causes issues in real life scenarios to begin with. If it’s determined it’s generally not causing a problem it’s just useless clutter in the UI.

    • Anastasia Kazakova says:

      March 21, 2019

      We never disturb users with memory indicator by default. In EAP we turned it on for more wider testing, now it’s off by default, but you can turn it on anytime in settings.

  2. okman says:

    March 22, 2019

    I found a problem with intelligent coding assistance. When some code like this:
    struct tagTest
    int a;
    int b;
    std::map<int, std::unique_ptr> mapTest;
    std::unique_ptr tagPtr (new tagTest);
    mapTest.insert(std::make_pair(1, std::move(tagPtr)));
    auto it = mapTest.find(1);
    if (it != mapTest.end())
    it->second->//after this point,I can’t see any tips.

    • Anastasia Kazakova says:

      March 22, 2019

      This is unfortunately an exiting bug – Thanks for pinging us

      • okman says:

        March 23, 2019

        Ok.And Which version will plan to fix this bug? . Thank you!

        • Anastasia Kazakova says:

          March 23, 2019

          I can’t provide you an estimate now. But we’ll reconsider it at our upcoming planning session for 19.2

  3. Npl says:

    March 22, 2019

    Second attempt at testing this ide, after several year.
    Improved heap and bounds.

    I am currently using eclipse and you can there push an executable across with ssh, then run gdbserver there and connect to it. Is something similar possible, only found how to connect to a running server?
    Running a script with variables from the target (path to executable and so on) would be enough

  4. jerryouyang says:

    March 26, 2019

    Any date for the final release?

    • Anastasia Kazakova says:

      March 26, 2019

      We hope to have it this week 😉

  5. michal says:

    March 27, 2019

    Let’s see if its faster than 2018.3.4 which is ridiculously slow. On two Xeons + 64 GB copy&paste of 2 lines of code can take 5 seconds. Typing can lag as well. I think it’s going to be the same in 2019.1 if you didn’t rewrite core indexing into native code. I will give a chance 2019.1 but if it’s still slow I quit to Visual Studio code.

    • Anastasia Kazakova says:

      March 27, 2019

      Not sure in native code it will be different. I mean JVM itself isn’t slow, however, algorithms and general architecture may have issues. And that’s exactly what we are fixing. Also, might make sense to check the memory usage and increase xmx in case it’s close to the limit.

      Cope&Paste might lag by different reasons: code reformatting is slow due to some issues, code analysis is slow, other problems. We can check what’s going on if you send us a CPU snapshot.


Subscribe for updates