CLion 2019.3.3 Bug-fix Update

Anastasia Kazakova

A new bug-fix update, CLion 2019.3.3, is now available for download! You can get build 193.6015.37 from our website, via the Toolbox App, or as a snap package (for Ubuntu). A patch update will be available shortly.

DOWNLOAD CLION

Here are the main highlights of the update:

  • Refactorings
    • Fix for the incorrect macro inlining (CPP-18442).
    • A regression in Extract Method has been fixed (CPP-18640).
  • Toolchains
    • Support for the /std:c++latest flag when using Microsoft Visual C++ Toolchain (CPP-16330).
    • The $PROJECT_NAME$ macro is now available (and refers to the CLion’s project name) in path-strings in configuration files for the project. This allows, among other things, the specification of a default CMake build directory outside of the project root (CPP-18172):
      default_dir
  • Editor
    • Raw strings are now recognized as literals in macro calls, thus eliminating false positives in the analysis.
    • Incorrect designated initializer highlighting has been fixed (CPP-18486).
  • Because of the exception failing, the Kotlin/Native plugin was blocking unit tests in CLion from running (CPP-18169). This issue has been resolved and the tests now run as expected.

We’ve also made various small improvements to name hints, concepts and Clangd-based code completion.

The full release notes are available here. If you are interested in learning about what’s coming to CLion in 2020, check out our roadmap. The CLion 2020.1 EAP will start soon – stay tuned!

DOWNLOAD CLION

Your CLion team
JetBrains
The Drive to Develop

Comments below can no longer be edited.

12 Responses to CLion 2019.3.3 Bug-fix Update

  1. Helge Penne says:

    January 23, 2020

    Thanks. You efforts to improve performance and reliability are clearly working. There are fewer freezes than before and things generally work as expected. The most annoying bug right now is this one:
    https://youtrack.jetbrains.com/issue/CPP-17875

    It would be nice if a C++ editor would allow me to type “~” characters, it is rather important for destructors. I hope you can prioritize this.

    Also, a fix for CPP-9623 would be most welcome.
    CPP-18804 should probably also be looked into.

    • Anastasia Kazakova says:

      January 23, 2020

      Thanks. All these are reasonable issues to fix, we’ll see if we can prioritize them.
      And I managed to reproduce CPP-18804 on my side, we’ll investigate it.

  2. ilya b says:

    January 23, 2020

    Thanks for the release! Typing performance is incredible, no crashes yet.

    I hope CLion team might look into the issue with slow sync in full-remote mode. I didn’t create the bug because this is how I believe the system is designed to work. However, I couldn’t switch to the full-remote scheme as my custom setup with rsync is so much faster.

    Header syncs in CLion in case of CMake tree changes are particularly terrible. For example, adding a file to CMake sources triggered the sync, as well as some other actions I can’t recall. Souce sync is not fast either.

    Overall I’d like to have more control over the sync procedures, possibly with an option to fully delegate syncing to the external scripts. My setup is pretty straightforward, project of ~100k LOC with several deps such as Boost as GRPC, remote host is fresh Xeon server with Linux. Syncing the remote codebase with rsync both ways during the usual editing/debugging takes no more than 2 seconds, while with CLion it’s easily 10s, 20s or more.

    Thanks anyway for the great work. Cheers.

    • Vasily Romanikhin says:

      January 26, 2020

      Thanks for feedback. Yes, we know that performance of “Reloading CMake Project” is our weak point. Please note that the most time-consumption step is collecting compiler information (not synchronisation itself). It means that for each unique compiler-switch we remotely create response-file and compiler-file, than run compiler and analyze output.
      But anyway you are right and we plan to continue work on performance in that part.

      • smekkley says:

        June 9, 2020

        If you can, could you please explain why that part takes much longer than local build? I noticed response-, compile- files are created on /tmp. Even without any change reload for one project takes 4 minutes while locally it’s instant with 3 cmake toolchains.

        • Vasily Romanikhin says:

          June 15, 2020

          First of all `”Reloading CMake Project” != Build`.
          “Reloading CMake Project” is building project model for correct work, code assistance, refactorings, etc. It means that IDE has to know all compiler features, defines, header roots. To collect this information we have to run compiler (in preprocessing mode) for each unique compiler-switch. It involves tons of remote processes calls and remote FS operations, as result this step (in current approach) takes so much time.

  3. Manuel Keßler says:

    January 24, 2020

    Hello,

    I just tried to upgrade from 2019.3.1 to 3.3 and got an error during the process mentioning a FileAlreadyExistsException on …Clion2019.3/system/log/idea.updater.files.XXX/backup.tmp.0 and “No files were changed. Please retry applying the patch.” My (admittedly wild) guess is that I did not upgrade to 3.2 previously and the upgrade of two patches simultaneously is not fully working. I find the two *-patch-*.jar files in …/system/tmp/patch-update, but apparently they can not be applied one after the other. Do you have a suggestion or is there a separate upgrade path option with 3.2 as an explicit intermediate step (assuming that is working well)?

    • Anastasia Kazakova says:

      January 24, 2020

      There are patches from 3.1 to 3.2 and from 3.2 to 3.3. And the whole chain should be applied automatically. If that doesn’t work for you, please, download a fresh 3.3 build from our site and install it. Sorry for the inconvenience, we’ll investigate what’s going on there.

  4. Taw says:

    January 29, 2020

    Anastasia, I really hope that you will fix CPP-18856, it’s very very ugly.
    CLion overwrites by gdb settings and sets the printed string len from “unlimited” to “1000” ? Why??
    I need big strings on some json requests, why CLion tries to be smarter that it is?

    • Anastasia Kazakova says:

      January 29, 2020

      We’ll discuss the reasoning behind that and will do our best to come up with some estimation on the improvement. Thanks.

    • Anastasia Kazakova says:

      January 29, 2020

      As far as I’ve learned, the reasoning behind this initiative was that GDB is setting a very low limit (200), so we did our best to increase it in CLion (to 1000). And usually, users don’t set this on their own) But of course, I agree that it should be done in another way – we should read the value first and then update to a bigger value if necessary. We’ll try to allocate resources and fix that when possible. Thanks for bringing our attention to this.

      • Tano says:

        January 30, 2020

        Thank you very much for your great support, Anastasia.

Subscribe

Subscribe for updates