CLion 2019.2 EAP: MSVC Debugger, Unused Includes Check, and More

Posted on June 26, 2019 by Anastasia Kazakova

Hi,

A new CLion 2019.2 EAP (build 192.5438.15) is now available. Download the full build from our site, install it via the Toolbox App, or use a snap package if you are using Ubuntu. A patch-update for the previous EAP build will be available shortly.

The main highlights:

DOWNLOAD CLION 2019.2 EAP

Experimental feature: Debugger for the Microsoft Visual C++ toolchain

For a long while, it’s been possible to use Microsoft compiler in CLion if you had the Microsoft Visual C++ toolchain installed on your Windows machine. However, the debugger was not available in CLion. This is because the Microsoft debugger is proprietary and cannot be used outside of Microsoft tools.

Now CLion is going to ship with an experimental debugger for the Microsoft Visual C++ toolchain!

‘Experimental’ means it’s limited and still has some major issues, listed below. So it’s definitely not release quality yet. We do encourage you to try and give us your feedback. This will help us identify how we can improve its functionality for you.

How to enable it?

As the debugger is experimental for now, you need to explicitly turn it on to use it. Call up the Maintenance dialog (Shift+Ctrl+Alt+/ on Linux/Windows, ⌥⇧⌘/ on macOS) | Experimental features, and select cidr.debugger.lldb.windows to control it.

Now, when you select the Visual Studio toolchain in CLion, the debugger is available:
msvc_toolchain

Known issues and diagnostics

As the feature is still in progress, here is a list of known issues, so please consider them before submitting any additional ones.

Native visualizers
For the Visual Studio C++ toolchain, STL native visualizers are taken from the Visual Studio installation. To enable them, use Settings | Build, Execution, Deployment | Debugger Data Views | Enable NatVis renderers for LLDB. Note, you can configure the proper diagnostics level here. Possible options are Disabled, Show only errors, or Verbose. (To report an error with renderers to our issue tracker, please select Verbose.)
msvc_settings

Not all of the STL types are rendered correctly in CLion (CPP-16661):

  • The following containers mostly work (in basic cases): string, list, vector, deque, array, stack, queue, priority queue, unordered_mutlimap, unordered_multiset, unordered_set, and unordered_map.
  • The following containers do not work: forward_list, map, set, multimap, and multiset.
  • Nested visualizers in containers are not yet supported.
  • There are a few known issues with the rendering of smart pointers in some cases.

By the way, if you have any custom native visualizers in your project, CLion will use them as well:
in_prj_natvis

Other known issues:

  • Data breakpoints are not yet supported.
  • Exception handling:
    • Break on exception throw/catch is not yet supported.
    • Stepping through the exception blocks has issues.
  • Target output may not be flushed on breakpoint hit.
  • Force step into the assembly code without debug symbols is not yet supported.
  • Thread names are not rendered.

How it works

The debugger is implemented by our team on top of LLDB. Even though we’ve upstreamed many changes introduced by this effort, there are still some things that are not available in the LLVM public repository. That’s why we bundle the proper version of custom LLDB within CLion.

What about LLDB on Windows in general?

Since the newly implemented debugger is based on LLDB, it’s reasonable to request it in other cases on Windows as well. Well, guess what? It is there! LLDB for MinGW is also present when the experimental feature is turned on.
mingw_toolchain

The implementation is also experimental as many standard containers and types are not rendered properly for now. For example, array and string should work fine, but for the rest of the standard containers there are some issues (monitor CPP-16660 for more details).

The ‘unused includes’ check is back

Since its launch, CLion has had a code check that detects and marks unused #include directives. However, some time ago we disabled it by default (in Settings / Preferences | Editor | Inspections | C/C++ | Unused code | Unused include directive) because of the many false positives.

Now the check is completely reimplemented on top of the Clangd-based language engine and is, again, enabled by default!
unused_incl_results

Note that if you disable the Clangd-based engine in CLion (which we do not recommend, as the engine not only speeds up code highlighting and other code assistance features, but also provides more accurate code errors and warnings), then the unused includes check will simply follow the old behavior.

Diagnostics strategies

There are several strategies you can follow to detect the unused or not required #includes directives and remove them:

  1. Detect completely unused: the most conservative strategy, which detects only the #includes directives with the declarations never used in the whole translation unit at all.
  2. Detect not directly used: this strategy follows the “Include What You Use” principle and detects the #includes directives with the declarations not used in the current file directly.
  3. Detect not required: the most aggressive strategy which detects the minimal subset of the #includes directives to keep the file compilable and suggests removing all the rest.

You can switch between the strategies in the inspection settings. By default, Detect not directly used is selected:
unused_incl_settings

How it works

To avoid false positives, we’ve set a few rules in the newly implemented inspection algorithm.

First, you can enable or disable running the inspection in the header files (by default, it’s disabled). If you decide to run the inspection in headers, then the “Umbrella headers” rule will be used. “Umbrella headers” are used to include all the necessary headers at once and contain no declarations at all. The inspection naturally doesn’t work for such headers.

Second, the source files with compilation errors will never get unused #includes directives – all directives will be considered used.

Finally, the inspection only checks the headers with #pragma or header guards. If none of them are present, the header will be always marked as used.

Memory view: ASCII view

CLion’s Memory view is improved in this EAP build. Earlier in 2019.2 EAP, we added Go to address. Now, behold the ASCII view:
mem_view_mingw

Better performance for code completion

Completion for qualified expressions has been significantly improved (CPP-16406). The boost is especially noticeable in LLVM project.

The full release notes are available here.

DOWNLOAD CLION 2019.2 EAP

Your CLion Team
JetBrains
The Drive to Develop

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

37 Responses to CLion 2019.2 EAP: MSVC Debugger, Unused Includes Check, and More

  1. Iliyan says:
    June 26, 2019 at 5:28 pm

    Nice release! Just upgraded and noticed that the colors in the side-by-side git diff viewer have disappeared. There are borders, but the background of modifies/inserted/deleted text is gone and so is the word highlighting. This makes this diff viewer quite unusable. Hope it’s a bug!

    Reply
  2. Roman Popov says:
    June 26, 2019 at 6:13 pm

    Cool, booted to Windows to give it a try. It feels like it works faster then on Linux, at least startup is faster. So debugger speed is already pretty good. Features (break on throw, etc) will be probably more important than performance optimizations.

    Reply
  3. Jonathan Ross says:
    June 26, 2019 at 6:50 pm

    I just gave the revamped unused include directive inspection a spin, and it’s looking very good. I encountered some minor issues:
    * Performance of running the inspection on my entire project is poor
    * (I think) I’ve seen a false positive involving forward declarations
    Would you like me to add tickets?

    Reply
  4. Dariusz Makowski says:
    June 26, 2019 at 8:43 pm

    OMG YESSSSSSS DEBUGGGGGGGG !!!!!!! <3 xxxxxxxxxxx

    Reply
    • Anastasia Kazakova says:
      June 26, 2019 at 8:44 pm

      Please mind the debugger is really experimental. Huge work is still ahead of us. But would be grateful if you try and report the feedback.

      Reply
  5. Tano says:
    June 27, 2019 at 7:04 am

    Only #pragma directives are accepted? Because #pragma is not part of the standard and cross-compile code usually use #ifdefs.

    Reply
    • Anastasia Kazakova says:
      June 27, 2019 at 12:26 pm

      As I say in the blog post, it works with pragmas and header guards. So all usual ways are supported.

      Reply
  6. James Dennet says:
    June 27, 2019 at 1:39 pm

    May I ask why you didn’t use Windows cdb.exe (I think from the Windows Debugger SDK)?
    I am just curious. Qt uses that. But it’s not actually too good – it can be very slow with large data structures, even crash, the visualization is not really great and often doesn’t even show variable’s contents etc. So I am actually very glad you are developing and improving your own solution using lldb. Just curious about your thoughts on cdb.exe.

    Reply
    • Anastasia Kazakova says:
      June 28, 2019 at 1:38 pm

      We experimented with it and hit a number of issues, the main one is that CDB is too slow on large binaries with lots of PDBs. Visual Studio uses its own debugging engine (unrelated to CDB), and if we wanted to provide a debugging experience comparable to VS, our only option was to make LLDB work better with binaries produced by the MSVC toolchain.

      Reply
  7. Henry Borchers says:
    June 27, 2019 at 2:48 pm

    yayayayayyayayayyay!!!!!!!!!!!!!!!!!!!!!! Thanks you! Thanks you! Thanks you!

    Reply
  8. ice1000 says:
    June 27, 2019 at 5:56 pm

    I really hope IntelliJ-Rust can follow your step to support msvc debugging.

    Reply
  9. blackj0221 says:
    June 27, 2019 at 6:52 pm

    What about LLDB for WSL? Isn’t it prepared yet?

    Reply
    • Anastasia Kazakova says:
      June 28, 2019 at 1:41 pm

      We haven’t considered it here. It’s a bit different story. Feel free to create a feature request.

      Reply
  10. Roman Popov says:
    June 27, 2019 at 8:16 pm

    I’ve noticed that LLDB on Linux does not allow to step into std::function. Is this a known problem?

    Reply
  11. Sad commenter says:
    June 27, 2019 at 9:20 pm

    > For a long while, it’s been possible to use Microsoft compiler in CLion if you
    > had the Microsoft Visual C++ toolchain installed on your Windows machine.
    > However, the debugger was not available in CLion. This is because the Microsoft
    > debugger is proprietary and cannot be used outside of Microsoft tools.

    WAT? What the hell does the debugger being proprietary have with supposedly not being usable “outside of Microsoft tools”. Visual C++ itself it proprietary and obviously can be used by third-party tools. You use it. The Debugging Tools for Windows (i.e. WinDbg) are also proprietary and they too can be used by third parties. IDA does it. Here’s another example: https://blogs.msdn.microsoft.com/ntdebugging/2010/06/30/i-want-a-debugger-robot/

    Have you TRIED using the VS debug interfaces (https://docs.microsoft.com/en-us/visualstudio/extensibility/debugger/reference/interfaces-visual-studio-debugging?view=vs-2019) or did some clever PM simply decided that “it’s proprietary so it cannot be used outside of Microsoft tools”, whatever that means?

    Reply
    • Anastasia Kazakova says:
      June 28, 2019 at 1:59 pm

      Ok, seems this requires some more detailed explanation: There are several debugging engine here. VS uses vsdebugeng.dll debugging engine, which we can’t use. CDB and WinGDB uses dbgeng.dll debugging engine (https://docs.microsoft.com/ru-ru/windows-hardware/drivers/debugger/debugger-download-tools). We first tried to implement a CDB-like debugger. However, the main issue is that CDB is too slow on large binaries with lots of PDBs. Visual Studio uses its own debugging engine, and if we wanted to provide a debugging experience comparable to VS, our only option was to make LLDB work better with binaries produced by the MSVC toolchain. Hope that explains the whole story.

      Reply
  12. Mark says:
    June 28, 2019 at 6:58 am

    From the previous version I have a problem after update. I use remote development, so after updating CLion I get message from deployment process that permission is denied. However if I downgrade back – there’s no error. Is it me doing something wrong or I should submit a bug for it?

    Reply
  13. Lawrence Millar-Madigan says:
    June 30, 2019 at 1:55 am

    This EAP is the most riddled with bugs I have ever seen from CLion, I certainly hope the final release is not in this state. All kinds of weird stuff like keyboard input suddenly not working, inputs not working for models and being routed to the console instead (wtf?) yikes

    Reply
  14. Alex says:
    July 4, 2019 at 12:23 pm

    I’ve upgraded from stable version and imported settings, however still have “Debugging is not yet supported with Visual Studio”.

    Also debugger and tools not showing up in toolchain dialog:
    https://imgur.com/a/6fIy7Zg

    Dialog updates on every focus capture but debugger and tools keep stuck.

    Reply
    • Eldar Abusalimov says:
      July 4, 2019 at 6:21 pm

      Have you enabled the cidr.debugger.lldb.windows experimental feature? The debugger selection is disabled on the toolchain settings page unless the experimental feature is turned on.

      Reply

Leave a Reply

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