Reopening / clarification of #452

[tromey]

Hi. We recently got a bug report against gdb asking that the configuration / launch logic be reimplemented (again). The bug is here: https://sourceware.org/bugzilla/show_bug.cgi?id=32090

This logic was originally redone in response to the clarifications in #452 (thank you).

However, that bug now points out that there was a different, earlier clarification to the launch process hidden away here: https://github.com/microsoft/vscode/issues/4902#issuecomment-368583522 ... but apparently not incorporated into the spec.

In particular the user is asking that gdb implement the "late case" in the above -- a scenario where, IIUC, a launch request is held and not responded to until after configurationDone.

Is this a supported / relevant scenario? If so, I think it should be documented in the spec. It would also be great to have some guidance as to which scenario adapters should support, and which ones clients could or should assume (or how they can even detect this).

[connor4312]

Thanks for digging that up, I hadn't seen that before -- 2018 was before my time :)

I agree we should clarify the specification here. I only now realize the diagram on the overview page previously referenced does include the constraints Andre referenced in the issue, but only by a very sneaky grey box on the left-hand side to represent an asynchonrous process 🙂

Essentially condensing what he said:

• A client may send a DA a launch/attach request at any point after receiving a response from capabilities
• A client should send the DA breakpoints and any necessary configuration on receipt of the initialized event (but this must not happen before capabilities are returned)
• A client must wait to effect (and respond to) the launch request until configurationDone

I wish this was more rigidly structured, this seems like it might have been a bit of a leak of VS Code's implementation into the protocol. But I don't think we have much wiggle room to change this in a backwards-compatible way.