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.
Here are the main highlights of the update:
- Refactorings
- Toolchains
- Support for the
/std:c++latestflag 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):
- Support for the
- 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!
Your CLion team
JetBrains
The Drive to Develop
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.
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.
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.
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.
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)?
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.
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?
We’ll discuss the reasoning behind that and will do our best to come up with some estimation on the improvement. Thanks.
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.
Thank you very much for your great support, Anastasia.