CLion 2019.1 EAP: Code highlighting with Clangd, Mute Variables in Debugger, and more


Here comes a new CLion 2019.1 EAP, build 191.4738.15! You can get it from our site, using Toolbox App, or through a snap package (if you are using Ubuntu). The patches will be available shortly for those of you who are using the previous EAP build.

Download CLion 2019.1 EAP

Clangd: code highlighting and quick-fixes

In 2018, we announced that we would work towards a complementary Clangd-based language engine and shared our big hopes for it. First, we implemented the error annotator on top of Clangd. Later came Clangd-based navigation and search (for some actions). And the first 2019.1 EAP starts with ClangFormat support, which we also kept as a part of Clangd. Now we’ve expanded the engine with code highlighting and quick-fixes!

For users, this means editor performance improvements. For code highlighting this change is clear, but for quick-fixes, it requires a bit of explanation. The Clangd-based language engine is used to identify potential breaches in the code and show an error or a warning. Now it’s also used to provide a location for a quick-fix, while CLion covers the actual quick-fix:

Unfortunately, for various reasons, some of the quick-fixes have been removed temporarily. You can find a list of them in the tracker: CPP-15243. We’re doing our best to fix the regression and put the most valuable quick-fixes from this list back in before the release. Make sure you let us know if your favorite one is on this list!

Clangd memory indicator

There is an increasing amount of functionality working on top of the Clangd-based language engine in CLion (mostly configured in Settings/Preferences | Languages & Frameworks | C/C++ | Clangd). Meanwhile, we plan to investigate the memory usage of the engine and turned on the memory indicator for the memory used by the Clangd-based engine in this EAP:
We might turn it off by default later, but for now let us know if you observe any suspicious usage there. (Besides, as a workaround, if you click on the indicator, CLion will restart the daemon.)

Mute variables in Debugger

While you are stepping through the code in debugger, the variables are calculated and the values are shown in variables view in the debugger tool window and right in the editor (Inline Variables View). There are cases, however, when it’s more important to step quickly and only watch the variables occasionally. So to improve the stepping performance in such cases, we’ve added an ability to Mute Variables. Most important facts about this new feature:

  • General per-IDE setting: the switcher is located in the context menu in the debugger tool window and mutes values calculation for all projects and all current and consequent debugger sessions (for both, GDB and LLDB). To unmute, turn off the setting.
  • Load values: each variable in the variables view gets a Load option. Click it to load the particular variable’s value at current step. The value won’t be recalculated on the next step.


Other improvements

A very useful fix has found its way into this build finally – now when you do a file rename, CLion doesn’t rename an associated class/struct silently, but asks instead if you’d like to rename it. And for sure, it works the other way round:

That’s it. The full release notes are here. Download and try the EAP build right now! We are looking forward to your feedback!

Download CLion 2019.1 EAP

Your CLion Team
The Drive to Develop

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

20 Responses to CLion 2019.1 EAP: Code highlighting with Clangd, Mute Variables in Debugger, and more

  1. Taw says:

    How do we turn off clang memory indicator? The CLion one is useful…thanks

    • Anastasia Kazakova says:

      Taw, clangd memory indicator was added on purpose to the EAP build (will likely be hidden by default in the release version) to catch all the suspicious situations on user’s projects when Clangd is in use. So we do not recommend you to turn it off. However, if you still willing to do so: Find Action -> Registry ->

  2. Anton says:

    Header files aren’t highlighted properly anymore. There’s just a basic syntax highlighting. Types and enumerations aren’t highlighted, as well as the long-suffering “override” keyword. I hope the next releases will improve the situation. Thank you for your hard work.

  3. Rogiel says:

    This and the first EAP versions seems to have a weird I/O bug. After a build, the entire UI always freezes and I need to kill the CLion process. On Windows Task Manager I see CLion constantly using over 200MB/s in I/O. Even though I have only tested the latest build on Windows, the same issue occurred with the previous build on the Mac.

    I have reported the bug with thread dumps attached as CPP-15306.

  4. Ernst says:

    clangd usage is up to 1Gb on a small project within 2000 code lines. does it look okay?

  5. Helge Penne says:

    clang format support seems to need work. For 2018.3 we had created a custom command that would run clang format. We had the CLion formatting set up to emulate our clang format settings as much as possible so that the code generated by CLion would be compliant with our clang format settings most of the time.

    The 2019.1 EAP is actually worse than 2018.3 for us, because when CLion uses the actual clang-format file, the code generated by CLion is LESS compliant with the clang format settings that the code generated by 2018.3 without clang format support. That is really strange and disappointing. It seems that the code generation inside CLion does not properly use clang format.

    The clang format support seems buggy and needs more work. Please do not release this in its current state, it is not ready. I filed one bug but there seem to be more:

  6. Helge Penne says:

    There is also this regression, which is fairly important:

  7. Kirill Sapozhnikov says:

    At last clangd is faster then standard language engine! Great work.
    Alas, is a problem for me too. Voted for this in youtrack.

  8. Ernst Maurer says:

    today , I’ve got wrong case because cut off some “unused methods” as CLion suggested.
    but codebase is a huge and later found that #define exists which enable/disable those code branches. and another value of that define puts those methods to “in use” state.
    looks clion code analysis doesn’t look at the defines (which can be re-defined depends of the build) . that’s sad (

Leave a Reply

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