Hi. Started to play with this. I've used VSCode for several years, though multi-process debugging capabilities make it a tad useless as a debugger.
Now what we need is something like https://marketplace.visualstudio.com/items?itemName=vsdbgplat.MicrosoftChildProcessDebuggingPowerTool#overview Something that will automatically attach any new process to the debugger. When will it be ready ? :D Jean-Yves On Wed, Sep 16, 2020 at 5:00 PM Andi-Bogdan Postelnicu <a...@mozilla.com> wrote: > > > On 16 Sep 2020, at 04:14, Botond Ballo <bba...@mozilla.com> wrote: > > On Tue, Sep 15, 2020 at 6:55 PM Jean-Yves Avenard <jyaven...@mozilla.com> > wrote: > >> This broke several features for me (and I use VSCode all the time). One in >> particular was the inability to switch between code and header (Ctrl-K >> Ctrl-O). >> > > clangd supports this, but it's under a custom command name (as it's not > part of the Language Server Protocol). > > Thank you for adding this, maybe we should also add to our documentation? > > If you go to Keyboard Shortcuts, and search for the command > "clangd.switchheadersource", you can bind your preferred shortcut to it. > > >> Finding symbol definition broke under many cases too. >> > > This is one we'd have to examine on a case-by-case basis. Some of them may > be upstream issues in clangd, but some may be issues in our setup (e.g. > related to unified builds). > > We should file a bug here an investigate on a per-module-basis, since from > our testing this feature works. I reckon that a problem may be triggered > with out unified build system. > > > Andi, do you have a suggestion for how to track these? Should we encourage > people to file Bugzilla tickets for them, which we can then triage (and if > appropriate, we can file upstream clangd issues)? > > Yes, we have Bug 1662709 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1662709> that is a META bug > acting as an aggregator for all bugs that are related with VSCode > deployment. All issues should block that bug and we should triage them. > My take on this is that if we find bugs in clangd extension or in clangd > itself we should upstream the fixes, at least for the clangd extension > since we don’t ship it in our environment. clangd on the other hand we ship > it in our artifacts so if we can’t upstream fixes, due to various reasons, > most probable they get to land in major or dot releases of clang, we apply > them locally when we build the artifacts. > > Cheers, > Botond > > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform