CLion 2019.3.3 Bug-fix Update

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

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

10 Responses to CLion 2019.3.3 Bug-fix Update

  1. Helge Penne says:

    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:

      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:

    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:

      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.

  3. Manuel Keßler says:

    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:

      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:

    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:

      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:

      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.

Leave a Reply

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