Vscode-cpptools: Separate Debugger from Language Service into two different extensions

[PhilParisot]

LLDB and GDB are very powerful tools that are used with more languages than just C/C++.

I use GDB with Rust for example on Ubuntu 20.04. I don't need the language service for C/C++.

But the main reason to do this would be to make it less confusing for folks getting started with LLDB/GDB for other languages when searching for extensions and to give more attention to the full functionality of LLDB/GDB with VS Code. This is an issue I ran into personally. There are no docs on how to get started with this extension with languages other than C/C++ and you have to dig through the documentation to find the debugging info relevant to you.

It's just a thought, but it would be awesome to give these debuggers more focused attention as a standalone VS Code extension.

[sean-mcmanus]

Yeah, we've talked about doing that in the past...we ended up adding the "C_Cpp.intelliSenseEngine": "Disabled" option instead, but that doesn't solve the discoverability issue with other languages. I would guess that the "other language" usage would have to meet some threshold of usage/requests.

Another good benefit would be the 2 components could update independently, so our language service could ship with just a 10 MB update instead of pulling in 10-30 MB for debugger bits that might not be updated at all.

@WardenGnaw Thoughts?

[PhilParisot]

Hey @WardenGnaw, I'd also like your thoughts on this <3

[pieandcakes]

It sounds like you want a flag to disable the downloading of the debugger dependencies. That would be a flag that could be added to when the activation happens to not download the dependencies.

[sean-mcmanus]

@pieandcakes I don't think that is what is being asked for. They said they're using the debugger with rust so they'll need those dependencies. They're asking to move the debugger functionality to a separate extension.

[WardenGnaw]

The debugger components shipped with this extension is primarly focused on the usage of C/C++ with the debug adapter (OpenDebugAD7/MIEngine).

The extension as a whole is to have a simple experience compiling and debugging C/C++. To keep this experience we would have to have a vscode extension pack that includes the seperated extensions.

Then if the laguage service package would to keep debugging functionality, they would need a dependency on the debugger side package.

As versitalie as GDB is, our main focus is C/C++.

As @pieandcakes mentions, we could have a flag to disable parts of this extension if users do not need the debugging functionality.

[bobbrow]

We do not plan to split the features out into two extensions at this time.

[PhilParisot]

@bobbrow I suggest we keep this ticket open in a backlog and not close it outright.

In the long run, if this extension remains focused solely on C/C++ it will hurt vscode support for GDB/LLDB.

In the interest of attracting talent and community support, I strongly suggest we decouple debugging and language support into two separate extensions, create an extension pack for C/C++ and refocus the debugging component to GDB and LLDB.

[bobbrow]

We appreciate your thoughts on the issue, but we do not intend to cut support for MSVC debugging either. I don't see how splitting debugging from the language server will improve vscode support for GDB/LLDB. All debugger work is being done out in the open either in this extension or in the MIEngine project. We welcome contributions to the debugger support from the community. That wouldn't change if we split the feature support into various extensions.

Additionally, for reference, Python, C#, and Go language extensions also bundle debugger support. It's a common expectation from developers.