vscode-rust VS vscode-cpptools

> it crashes process IDs more often than Justin Bieber crashes Maseratis: https://github.com/rust-lang/vscode-rust/issues/890

So -- this guy used an extension (named Rust) with rust-analyzer, which was known to not work, and it didn't work(!), and the Rust extension author recommends he tries the extension made for rust-analyzer. That extension doesn't have the features he likes (it works for me and has loads of features, so I have no idea what this is about?), and so they close the issue?

Hardly a case for the ages. Guy uses unsupported config and things don't work?

> What clangd does is work.

Don't doubt it. I'm just saying -- I haven't had any problems with the rust-analyzer extension since it became the Rust default. But, yes, I had a few hiccups and crashes beforehand, no doubt. I just have to imagine it's both younger, and doing more/different things than clangd.

I know. It's been argued for a long time. But at least if you follow the advice to install RA, it's fine. And if you don't, you won't be able to install RLS anyway, but instead get a helpful message pointing to RA.

But the last commit to the Code extension was almost one year ago (an URL update), a pull request for a pretty annoying issue was not merged in more than a year, and the only activity on the issue tracker is people complaining about old issues and sometimes me asking them nicely to try rust-analyzer instead (but only when I'm pretty certain that their issue does not happen in RA).

It's been asked before: https://github.com/rust-lang/vscode-rust/issues/927. Basically, rust-analyzer is not (yet?) a rust-lang.org project and it's not even going to be mentioned in the official docs until that happens.

Yeah, see e.g. https://github.com/rust-lang/vscode-rust/issues/880.

RA will be merged with the vscode-rust extension and aims to replace RLS (tracking issue on the vscode-rust repo).

The C/C++ extension is open source with MIT license but the shipped extension binary contains MS proprietary binaries that is not as open [1]. I am not sure what will be the difference between using MS official build and compiling the source (there will be some for sure).

[1] https://github.com/microsoft/vscode-cpptools/blob/main/LICEN...

Now if only MS would fix VSCode[0] :'(. Come on, the feature if more than half a decade old and this point.

0: https://github.com/microsoft/vscode-cpptools/issues/6302

🔗 Link to GitHub Issue: Add Similar Function - https://github.com/microsoft/vscode-cpptools/issues/11477

According to this: https://github.com/microsoft/vscode-cpptools/issues/3423 it seems to be at least somewhat possible to reuse natvis files from Visual Studio, but I have not tested that. Never really had the need to look at any non-vector container in the debugger.

Thank you for the feedback! Perf is always an ongoing issue for us but I can say that we’ve recently allocated one of our senior engineers to take on more perf related issues. Something that really helps us out is if you could file reproducible steps that lead to your performance issue. This allows us to address the issues more readily. Please file your issues here: https://github.com/microsoft/vscode-cpptools/issues

Yes, see this github issue for an example: Add Ada to supported languages for debugging · Issue #10475 · microsoft/vscode-cpptools (github.com)

Nope https://github.com/microsoft/vscode-cpptools/issues/16

and finally, it you're not happy using the extension I provided you, try fo contact the C/C++ Extension repo on GitHub, they'll help you out with your issue. Here's the link: https://github.com/microsoft/vscode-cpptools