Open source Microsoft C++ extension for VSCode

[outcoldman]

Please open source Microsoft C++ extension

[delmyers]

The extension uses several open source components. Most significantly, the debugger is based off of the open-source Microsoft MiEngine here:

http://GitHub.com/Microsoft/miengine

[outcoldman]

@delmyers great, this should make it really easy to open source the extension itself ;)

[ivomachado]

Any updates on this?

[sean-mcmanus]

The Microsoft.VSCode.CPP.Extension.exe language service contains code shared with VS that we cannot open source due to license issues. Theoretically, the code could be re-written to allow open-sourcing but it would take a non-trivial amount of work. Feel free to let us know why you believe open sourcing would be valuable. Would people be interested in contributing bug fixes and features?

[outcoldman]

@sean-mcmanus why did you close this issue? it was not delivered

Yes, people are interested in contributing.

The Microsoft.VSCode.CPP.Extension.exe language service contains code shared with VS that we cannot open source due to license issues.

In case when gdb or lldb is used, I don't believe it should have such complicated layering.

[sean-mcmanus]

I thought we were closing issues we didn't intend to fix? Our extension has language service and debugger components, so the debugger team might be able to open source more of their code. I guess we can keep this open if you want.

[delmyers]

@outcoldman, This extension is made up of components, some of which are open, and some of which are not. For example, it uses the Mono runtime on Linux and Mac, which is open. The component that is used for debugging on Linux and Mac (minus a stub component used to launch the debugger and translate protocols) is also open (linked above). The debugger for Windows can't be open sourced, unfortunately, at this time.

[outcoldman]

@delmyers what about the extension itself? The one which integrates into VS Code?

[delmyers]

@outcoldman Most of the extension itself is just a composition of the components that I mentioned above, plus some configuration and launching scripts. I suppose we could consider open-sourcing the configuration file? Is that something that you would see as worth-while?

[outcoldman]

Yep, launching scripts I guess will be useful as well.

[jhasse]

The debugger for Windows can't be open sourced, unfortunately, at this time.

Does this also include the debugging part when using GDB on Windows?

[masaeedu]

@delmyers I'm most interested in the language service that provides (or will provide) Intellisense for C++. For the current fuzzy intellisense experience, how are you obtaining the symbols throughout the codebase? Is this something that can be open sourced? Is it e.g. based on Clang, or some proprietary analysis engine for C/C++ code?

[sean-mcmanus]

Our browse database and the IntelliSense engines are closed source and not based on clang. It can't be open sourced due to non-open sourced license dependencies.

[masaeedu]

@sean-mcmanus Fair enough, thanks for the info. I think it might still be very useful if you could introduce a clean boundary between the language service itself and whatever proprietary tools you're using to supply analysis data. That way you get open source contribution to the language service, and the community gets the ability to build an analysis engine on top of Clang/GCC guided by the language service's needs. The reason I was interested in this is because a semantic analysis engine (something analogous to the bind phase API of Roslyn) appears to be missing from the C/C++ ecosystem.

[sean-mcmanus]

The typescript part of our extension has been open sourced: https://github.com/Microsoft/vscode-cpptools . The 2 language server processes that do parsing stuff haven't been open sourced.

[amelvill-umich]

Feel free to let us know why you believe open sourcing would be valuable. Would people be interested in contributing bug fixes and features?

Yes, I would be interested in reading and contributing to this. I have found some limitations that I'd like to try and work around.

The 2 language server processes that do parsing stuff haven't been open sourced.

Unfortunately I think everything I'd be interested in would be in these server processes.