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
Ktor
News
Team
JetBrains PlatformCLion 2019.2 EAP: MSVC Debugger, Unused Includes Check, and More
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:
- Experimental feature: Debugger for the Microsoft Visual C++ toolchain
- The ‘unused includes’ check is back
- Memory view: ASCII view
- Better performance for code completion
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:
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.)
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:
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?
Upd. LLDB for MinGW was disabled in the final release 2019.2 and is not supported for now.
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.
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!
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:
- Detect completely unused: the most conservative strategy, which detects only the
#includesdirectives with the declarations never used in the whole translation unit at all. - Detect not directly used: this strategy follows the “Include What You Use” principle and detects the
#includesdirectives with the declarations not used in the current file directly. - Detect not required: the most aggressive strategy which detects the minimal subset of the
#includesdirectives 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:
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:
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.
Your CLion Team
JetBrains
The Drive to Develop
Iliyan says:
June 26, 2019Nice 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!
Iliyan says:
June 26, 2019Oh, I now see it’s actually a feature. The diff colors appear if the file/block is included for committing. This makes sense, but having no colors at all when it’s excluded makes diffing harder 🙁
Anastasia Kazakova says:
June 26, 2019Submit a ticket to IDEA tracker please, EAP is exactly for collecting such feedback, thanks.
Iliyan says:
June 26, 2019Thanks, Anastasia!
Created a ticket:
https://youtrack.jetbrains.com/issue/CPP-16679
Roman Popov says:
June 26, 2019Cool, 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.
Anastasia Kazakova says:
June 26, 2019Thanks! Glad you liked it.
Jonathan Ross says:
June 26, 2019I 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?
Anastasia Kazakova says:
June 26, 2019Thanks.
You are right, we also observe some performance issues with bulk mode: https://youtrack.jetbrains.com/issue/CPP-16670
Regarding the false positives, please file the ticket with a code sample.
Jonathan Ross says:
June 27, 2019I added https://youtrack.jetbrains.com/issue/CPP-16694.
Are there any plans to further expand this functionality? One of the features I love in `include-what-you-use`, is the ability for it to suggest forward declarations – I would like to see this in CLion too; hopefully this will soon evolve into a reliable ‘optimize #includes’ function to rival IDEA’s optimize imports.
Anastasia Kazakova says:
June 28, 2019Thanks, we’ve managed to reproduce, will check it.
Replacing with forward declarations is a nice feature indeed – https://youtrack.jetbrains.com/issue/CPP-9117. We’ll consider it for further improvements.
Dariusz Makowski says:
June 26, 2019OMG YESSSSSSS DEBUGGGGGGGG !!!!!!! <3 xxxxxxxxxxx
Anastasia Kazakova says:
June 26, 2019Please mind the debugger is really experimental. Huge work is still ahead of us. But would be grateful if you try and report the feedback.
Tano says:
June 27, 2019Only #pragma directives are accepted? Because #pragma is not part of the standard and cross-compile code usually use #ifdefs.
Anastasia Kazakova says:
June 27, 2019As I say in the blog post, it works with pragmas and header guards. So all usual ways are supported.
James Dennet says:
June 27, 2019May 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.
Anastasia Kazakova says:
June 28, 2019We 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.
Henry Borchers says:
June 27, 2019yayayayayyayayayyay!!!!!!!!!!!!!!!!!!!!!! Thanks you! Thanks you! Thanks you!
ice1000 says:
June 27, 2019I really hope IntelliJ-Rust can follow your step to support msvc debugging.
Anastasia Kazakova says:
June 28, 2019The team is looking at it as well, but since it’s experimental even for C++, Rust team is a now bit behind.
John says:
July 2, 2019One of the intellij-rust developers commented they are working on it.
https://github.com/intellij-rust/intellij-rust/issues/535#issuecomment-507572415
blackj0221 says:
June 27, 2019What about LLDB for WSL? Isn’t it prepared yet?
Anastasia Kazakova says:
June 28, 2019We haven’t considered it here. It’s a bit different story. Feel free to create a feature request.
Roman Popov says:
June 27, 2019I’ve noticed that LLDB on Linux does not allow to step into std::function. Is this a known problem?
Anastasia Kazakova says:
June 28, 2019There is a bunch of issues linked to this one https://youtrack.jetbrains.com/issue/CPP-10235, but don’t see anything in particular about std::function. Can you please submit a report with a code sample?
Sad commenter says:
June 27, 2019> 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?
Anastasia Kazakova says:
June 28, 2019Ok, 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.
Mark says:
June 28, 2019From 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?
Vasily Romanikhin says:
July 2, 2019Hello.
In latest release new SSH backend is enabled by default.
Could you please open Registry (`Help -> Find Action -> type “Registry”`) and disable the follow properties:
`ide.ssh.library.backend.use.sshj`
`ide.ssh.library.backend.webDeployment.use.sshj`
Then could you please try again, if it helps you please file a ticket to https://youtrack.jetbrains.com/issues/CPP
Thanks in advance.
Mark says:
July 3, 2019Vasiliy, thanks a lot for reply.
I’ve tried the actions you have proposed and it helped.
I’ve created a ticket. It’s available here: https://youtrack.jetbrains.com/issue/CPP-16735
Lawrence Millar-Madigan says:
June 30, 2019This 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
Anastasia Kazakova says:
July 1, 2019Could you please submit the exact cases with code samples, screenshots or other details to our tracker? It’s hard to improve w/o knowing that information.
Helge Penne says:
July 2, 2019I also have problems with keyboard input not working. It seems to happen when pasting:
https://youtrack.jetbrains.com/issue/CPP-16723
This is a super-critical bug that will annoy users terribly. The backlash will potentially be huge if you release this.
Anastasia Kazakova says:
July 2, 2019Thanks, we’ll investigate.
Alex says:
July 4, 2019Tools catching up finally, but debugger still absent
Alex says:
July 4, 2019I’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.
Eldar Abusalimov says:
July 4, 2019Have 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.
Alex says:
July 15, 2019Ah, sure, it managed to work after enabling it, thank you
Yakov says:
November 14, 2019Is there a way to disable unused #include inspections for a specific header (other than wrapping it inside an umbrella) or a specific #include statement (similar to “IWYU pragma: keep”)
Anastasia Kazakova says:
November 14, 2019I’m afraid no, but this sounds like an interesting idea. Feel free to create a feature request here: https://youtrack.jetbrains.com/issues/CPP
Monet says:
November 18, 2019Hello, i am tring to use lldb on windows with mingw-w64 toolchain, and i have enabled the cidr.debugger.lldb.windows, but I can not find “Bundled LLDB” option on the drop down box, and even no “Bundled GDB” here, did I missed anything ?
Screenshot:
https://imgur.com/a/dDXlt9y
Anastasia Kazakova says:
November 18, 2019LLDB on Windows is a speacial LLDB customized by the JetBrains team to work with the Visual Studio toolchain. It’s not enabled for MinGW or MinGW-w64.
Monet says:
November 18, 2019Thanks for your response firstly.
But you have talked this at the section of “What about LLDB on Windows in general?”
and at there, you said “LLDB for MinGW is also present when the experimental feature is turned on.”
And on that screenshot, it does “enabled for MinGW” on Windows exactly.
Anastasia Kazakova says:
November 18, 2019Sorry, probably post have to be updated. We’ve enabled LLDB on MinGW in one EAP build, but then had to disable it due to many issues. So it’s not supported for now