AppCode
CLion
DataGrip
GoLand
IntelliJ IDEA
MPS
PhpStorm
PyCharm
Rider
RubyMine
WebStorm
Toolbox App
.NET Tools
ReSharper C++
Space
TeamCity
Upsource
YouTrack
Datalore
Hub
Kotlin
KtorCLion 2018.3 EAP: clangd-based navigation and search, CPU Profiler and remote mode improvements
Hi,
Please welcome a new CLion 2018.3 EAP (build 183.4284.40)!
As usual, a patch-update will be available shortly for those using the previous EAP build, and you can also use Toolbox app or snap packages (in the case of Ubuntu) to get this build.
No license is required and the build is free to use, but it will expire within 30 days of the build date.
Clangd-based navigation and search
In CLion 2018.2 we’ve introduced an experimental complementary language engine, based on Clangd. Initially it worked only as an error annotator, providing code errors and warnings in the editor. Now it’s also used by CLion for some navigation and search actions:
- Go to declaration (
Ctrl+Bon Win/Lin,⌘Bon macOS) / go to definition (Ctrl+Alt+Bon Win/Lin,⌥⌘Bon macOS). - Highlighting references under caret.
- Quick Documentation popup (
Ctrl+Qon Win/Lin,F1on macOS) - Find Usages (
Alt+F7) – it uses Clangd-based engine to search through the files opened currently in the editor and CLion’s own engine for all the other usages.
CLion’s own engine is still in use for all the actions not listed above and also for the cases when Clangd-based engine fails. Besides, CLion adjusts the results it gets from Clangd in some cases (for example, it goes to the constructor not class declaration, when navigating from the constructor call).
Clangd-based language engine in CLion is turned on by default on all platforms. You can change the default configuration in Settings/Preferences | Languages & Frameworks | C/C++ | Clangd:
Note that if you’d like to turn off the Clangd-based engine completely in CLion, you need to uncheck all the options in this dialog.
Navigation in CPU profiler, fixes for remote and more
Jump to Source action in CPU Profiler tool window now works not only on Linux, but on macOS as well:
Remote mode was improved in this build thanks to a few important fixes delivered:
- An ability to exclude paths when synchronizing the sources to the remote machine for remote toolchains in CLion (CPP-14275).
- Different deployment configurations are now used for different toolchains (CPP-14014). This also allows to copy remote toolchain correctly (CPP-14626).
Full release notes are available here.
Your CLion Team
JetBrains
The Drive to Develop
Tano says:
November 8, 2018Hi Anastasia, are there any benefits for using clangd for navigation and search?
I am asking because CLion already does a great job without it and I don’t know if I should activate it or not. thanks
Anastasia Kazakova says:
November 8, 2018It’s activated by default now. And it provides more accurate results, moreover quite often it works quicker than just CLion’s own engine.
Roman says:
November 8, 2018IMO, you should focus on generators and refactorings instead of navigation, they are the most annoying problem now.
Anastasia Kazakova says:
November 8, 2018There are issues in many areas. However, refactorings require a global symbol cache and we are still not sure they are doable on clangd-engine at all. While I can assure you we are running the corresponding experiments internally.
Richard Szabo says:
November 9, 2018Thanks for CLion it is a great tool for multi platform C++ development. I like the speed the IDE development moves. Nice new features and improvements.
Here are some remarks :
Please try out features with complicated use cases. I’m using clion for cmake based project with 100+ libraries 5+ configuration / cross compiling custom OS / Bare metal …
And the most tricky part is the heavy code generators with DSLs … (here refactoring dies today … it refactors on generated code … even it is marked in cmake that it is generated and a result of a custom command. ). But navigation is getting there after some restart it getting most of it done which is remarkable compare to any other IDE is doing a way much worst.
Never the less new features need improvements like if I have several cmake configuration configured it allays rebuilds all and it is taking considerable time we generate CTEST 1000+ of them I have a particular config selected I’m interested there why can we just ignore the others and rebuild them if I change the config ?.
remote building and running and compiling is very nice feature we have build machines with 40+ cores where this becomes really handy … but opening an SSH session for each file to be stored on the remote side is make the feature completely unusable in remote VPN with 100.000 files + which we have.
And it comes to my point please make progress on CTEST integration …
For tool chain specification would be nice If I could be able to give a shell script which would be sourced to the shell in which the compiler /c make runs. we have chrooted environments.
and by just having environment variables and path influence in the tool chain configuration sometimes impossible to achieve or requires considerable effort.
So keep up the good work I will stay tuned
Anastasia Kazakova says:
November 9, 2018Thank you for your comment. All described directions are definitely important and we hope to improve CLion in these directions.
CTest request: https://youtrack.jetbrains.com/issue/CPP-905
Could you please submit toolchains requests to the tracker and describe the cases in details there?
long2015 says:
November 13, 2018Hi Anastasia， There is another situation about remote-host that No Need upload source file to remote. If possible，please support it.
Our source file is on Ubuntu server, so we compile it on Ubuntu. But we editor the same source file on windows H: disk, use Clion. Because the Ubuntu Server source file is mounted to H: disk on windows.
So it’s mean when I modify file on windows, I no need upload file to Ubuntu server manually, The smb server do it.
Also when use Remote Host mode on windows, no need upload file, we only need to specify the smb mount directory.
I’m not sure if I say cleary.
Anastasia Kazakova says:
November 13, 2018Yes, we have such configuration in plans for the future. Not this release, however.
Tano says:
November 14, 2018Anastasia, is there a hidden option so I can disable auto-generate #include in CLion? (CPP-5501)
At least 5-6 times a day I have to delete the wrongly generated #include, although the correct one already exists…
#include “protocol/protocol.hpp” // mine
#include // CLion adds this, why???
Thank you
Anastasia Kazakova says:
November 14, 2018Which action do you call/what do you do when the wrong include is added?
In general, there is a set of options under Settings/Preferences | Editor | General | Auto Import | C/C++ group, which you can disable.
Tano says:
November 14, 2018I don’t know exactly when, I just see the new line added there before I commit, I will disable the auto-import entirely, thanks.
Tano says:
November 15, 2018Yeah, it did not work, CLion keeps adding includes, mostly wrong, because the correct one already exist…
Anastasia Kazakova says:
November 15, 2018Could you please take a look which action adds it? There are some actions not covered by the setting, just need to understand which one.
Tano says:
November 15, 2018Another question, it seems that I don’t have any autocomplete anymore in my project, is there a setting to reset these kind of stuff in order to make it work again?(CPP-14705)
Anastasia Kazakova says:
November 15, 2018It seems the full sample is much appreciated. Both problems seem to be coming from some incorrect resolve for some symbols…
Tano says:
November 15, 2018Hmm, invalidate cache and restart fixed it, I hope it lasts…
Anastasia Kazakova says:
November 15, 2018Does it fix the incorrect auto import as well?
Alex says:
November 15, 2018Thank you very much for your work on remote toolchains! I’m very excited to try this out.
Since you have been doing lots of work on toolchain selection lately, is there any chance you could also look at changing the CMake generator between Makefiles and Ninja (https://youtrack.jetbrains.com/issue/CPP-2659)?
It seems like all that needs to change is passing -G “CodeBlocks – Ninja” instead of -G “CodeBlocks – Unix Makefiles” to cmake?
This would massively reduce build times for us and would make CLion so much more usable to work on large projects such as LLVM/Clang.
Anastasia Kazakova says:
November 15, 2018The problem is not that we can’t change the generator command, but that Ninja output format lacks some information we need to load the project. This probably will be solved by using CMake server. We plan to take a look at it next year.
Alex says:
November 15, 2018Thanks for this information. So does this mean Clion actually parses the generated makefiles instead of the using .cbp file (which would also exist when using the ninja generator)?
Very much looking forward to the CMake server support.
Anastasia Kazakova says:
November 15, 2018We do parse the makefiles output due to several reasons.