diff options
author | John Harrison <harjohn@google.com> | 2025-05-16 19:28:34 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-05-16 19:28:34 -0700 |
commit | 0e0b501bf53677105b539fa4f84cbfb76c46f74d (patch) | |
tree | 8fcf77030b014c65606bbb80ef4acec56050f64b /clang/lib/Frontend/CompilerInvocation.cpp | |
parent | 9178a1720667807aa46dcfc3069bad7e8fef5f2e (diff) | |
download | llvm-0e0b501bf53677105b539fa4f84cbfb76c46f74d.zip llvm-0e0b501bf53677105b539fa4f84cbfb76c46f74d.tar.gz llvm-0e0b501bf53677105b539fa4f84cbfb76c46f74d.tar.bz2 |
[lldb-dap] Take two at refactoring the startup sequence. (#140331)
This is more straight forward refactor of the startup sequence that
reverts parts of ba29e60f9a2222bd5e883579bb78db13fc5a7588. Unlike my
previous attempt, I ended up removing the pending request queue and not
including an `AsyncReqeustHandler` because I don't think we actually
need that at the moment.
The key is that during the startup flow there are 2 parallel operations
happening in the DAP that have different triggers.
* The `initialize` request is sent and once the response is received the
`launch` or `attach` is sent.
* When the `initialized` event is recieved the `setBreakpionts` and
other config requests are made followed by the `configurationDone`
event.
I moved the `initialized` event back to happen in the `PostRun` of the
`launch` or `attach` request handlers. This ensures that we have a valid
target by the time the configuration calls are made. I added also added
a few extra validations that to the `configurationeDone` handler to
ensure we're in an expected state.
I've also fixed up the tests to match the new flow. With the other
additional test fixes in 087a5d2ec7897cd99d3787820711fec76a8e1792 I
think we've narrowed down the main source of test instability that
motivated the startup sequence change.
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions