CLion 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.

Download CLion 2018.3 EAP

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+B on Win/Lin, ⌘B on macOS) / go to definition (Ctrl+Alt+B on Win/Lin, ⌥⌘B on macOS).
  • Highlighting references under caret.
  • Quick Documentation popup (Ctrl+Q on Win/Lin, F1 on 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:
clangd_preferences
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:
jump_to_source_cut

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

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

21 Responses to CLion 2018.3 EAP: clangd-based navigation and search, CPU Profiler and remote mode improvements

  1. Tano says:

    Hi 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:

      It’s activated by default now. And it provides more accurate results, moreover quite often it works quicker than just CLion’s own engine.

  2. Roman says:

    IMO, you should focus on generators and refactorings instead of navigation, they are the most annoying problem now.

    • Anastasia Kazakova says:

      There 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.

  3. Thanks 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

  4. long2015 says:

    Hi 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.

  5. Tano says:

    Anastasia, 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:

      Which 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.

  6. Alex says:

    Thank 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:

      The 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:

        Thanks 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.

Leave a Reply

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