llvm-project.git/lldb/test/API/tools/lldb-dap/stackTraceDisassemblyDisplay/TestDAP_stackTraceDisassemblyDisplay.py, branch main Unnamed repository; edit this file 'description' to name the repository. [lldb-dap][test] create temp source file in test directory. (#163383) 2025-10-15T10:55:29+00:00 Ebuka Ezike yerimyah1@gmail.com 2025-10-15T10:55:29+00:00 e249c5101003cec2c885ea825a0be9fc24fa422d Fixes #163288 --------- Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com> 
Fixes #163288

---------

Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
 [lldb-dap] Take two at refactoring the startup sequence. (#140331) 2025-05-17T02:28:34+00:00 John Harrison harjohn@google.com 2025-05-17T02:28:34+00:00 0e0b501bf53677105b539fa4f84cbfb76c46f74d 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. 
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.
 [lldb-dap] Change the launch sequence (#138219) (reland) 2025-05-07T23:20:47+00:00 Jonas Devlieghere jonas@devlieghere.com 2025-05-06T22:58:44+00:00 aeeb9a3c09f40f42a1e8e5e3c8dbde3b260744bd This PR changes how we treat the launch sequence in lldb-dap. - Send the initialized event after we finish handling the initialize request, rather than after we finish attaching or launching. - Delay handling the launch and attach request until we have handled the configurationDone request. The latter is now largely a NO-OP and only exists to signal lldb-dap that it can handle the launch and attach requests. - Delay handling the initial threads requests until we have handled the launch or attach request. - Make all attaching and launching synchronous, including when we have attach or launch commands. This removes the need to synchronize between the request and event thread. Background: https://discourse.llvm.org/t/reliability-of-the-lldb-dap-tests/86125 
This PR changes how we treat the launch sequence in lldb-dap.

 - Send the initialized event after we finish handling the initialize
   request, rather than after we finish attaching or launching.
 - Delay handling the launch and attach request until we have handled
   the configurationDone request. The latter is now largely a NO-OP and
   only exists to signal lldb-dap that it can handle the launch and
   attach requests.
 - Delay handling the initial threads requests until we have handled
   the launch or attach request.
 - Make all attaching and launching synchronous, including when we have
   attach or launch commands. This removes the need to synchronize
   between the request and event thread.

Background:
https://discourse.llvm.org/t/reliability-of-the-lldb-dap-tests/86125
[NFC][lldb] Fix unresolved test in buildbot lldb-aarch64-windows (#137516) 2025-04-27T14:32:43+00:00 Ebuka Ezike yerimyah1@gmail.com 2025-04-27T14:32:43+00:00 ee4b34cf3292382b153ba777fa1092858bea13f5 object indexing causes key error. Initial commit #290ba2 
object indexing causes key error.

Initial commit #290ba2
 [lldb-dap] Show assembly depending on `stop-disassembly-display` settings (#136494) 2025-04-25T21:35:20+00:00 Ely Ronnen elyronnen@gmail.com 2025-04-25T21:35:20+00:00 290ba281e819d60be4903436cbc07efc12e22d4c Show assembly code when the source code for a frame is not available in the debugger machine Edit: this functionality will work only when using `stop-disassembly-display = no-source` in the settings Fix #136492 After the fix: [Screencast From 2025-04-20 18-00-30.webm](https://github.com/user-attachments/assets/1ce41715-cf4f-42a1-8f5c-6196b9d685dc) 
Show assembly code when the source code for a frame is not available in
the debugger machine

Edit: this functionality will work only when using
`stop-disassembly-display = no-source` in the settings

Fix #136492

After the fix:

[Screencast From 2025-04-20
18-00-30.webm](https://github.com/user-attachments/assets/1ce41715-cf4f-42a1-8f5c-6196b9d685dc)