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

Reply via email to