[Lldb-commits] [lldb] [lldb-dap] Refactor request handlers (NFC) (PR #128262)

2025-02-24 Thread John Harrison via lldb-commits
ashgti wrote: I think making the `operator ()` const makes sense, to help ensure we don't add any state accidentally. I can't think of any requests that have state at the moment. All the state is stored in the DAP object. Create an instance for each request might be helpful if we have more com

[Lldb-commits] [lldb] [lldb-dap] Refactor request handlers (NFC) (PR #128262)

2025-02-24 Thread Jonas Devlieghere via lldb-commits
JDevlieghere wrote: > LLVM Buildbot has detected a new failure on builder `lldb-remote-linux-win` > running on `as-builder-10` while building `lldb` at step 8 "build-default". Should be fixed by 51ce6c437fec1fe0170d077424e1cbc141d05c2b https://github.com/llvm/llvm-project/pull/128262

[Lldb-commits] [lldb] [lldb-dap] Refactor request handlers (NFC) (PR #128262)

2025-02-24 Thread LLVM Continuous Integration via lldb-commits
llvm-ci wrote: LLVM Buildbot has detected a new failure on builder `lldb-remote-linux-win` running on `as-builder-10` while building `lldb` at step 8 "build-default". Full details are available at: https://lab.llvm.org/buildbot/#/builders/197/builds/2395 Here is the relevant piece of the bui

[Lldb-commits] [lldb] [lldb-dap] Refactor request handlers (NFC) (PR #128262)

2025-02-24 Thread Jonas Devlieghere via lldb-commits
JDevlieghere wrote: That's a good question. The non-constness of the operator was an oversight, I meant for the classes to be stateless and mimic the current implementation. Adding he `const` is trivial and I can do that before migrating more requests, but that's pointless if we want to make t

[Lldb-commits] [lldb] [lldb-dap] Refactor request handlers (NFC) (PR #128262)

2025-02-24 Thread Pavel Labath via lldb-commits
labath wrote: I suppose an interesting practical question is whether a specific request needs to "know" whether it has been (is being) cancelled (or whether the SBDebugger flag suffices). If it does, then I think it would be natural to store this state in the request object, but then really ou

[Lldb-commits] [lldb] [lldb-dap] Refactor request handlers (NFC) (PR #128262)

2025-02-24 Thread Pavel Labath via lldb-commits
https://github.com/labath commented: I am thinking about how would this new approach work if we started executing requests in parallel (I know we're not planning to do that now, but this sort of started out from that), and it seems to me that the this design (a "singleton" object with a non-co

[Lldb-commits] [lldb] [lldb-dap] Refactor request handlers (NFC) (PR #128262)

2025-02-23 Thread Jonas Devlieghere via lldb-commits
https://github.com/JDevlieghere closed https://github.com/llvm/llvm-project/pull/128262 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-dap] Refactor request handlers (NFC) (PR #128262)

2025-02-23 Thread Jonas Devlieghere via lldb-commits
https://github.com/JDevlieghere edited https://github.com/llvm/llvm-project/pull/128262 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-dap] Refactor request handlers (NFC) (PR #128262)

2025-02-23 Thread Jonas Devlieghere via lldb-commits
https://github.com/JDevlieghere edited https://github.com/llvm/llvm-project/pull/128262 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits