da-viper wrote:
> Would it be possible to have the RequestHandlers advertise whether or not
> they should be deferred until the configuration is done (e.g.
> DeferredUntilConfigurationDone), and keep the latter an implementation detail
> of the DAP class? And strictly handle deferring at the queue level?
Yes it can,
> What I don't like is how this introduces more statefulness, especially in the
> request handlers. The queueing/deferring logic isn't trivial and I would
> strongly prefer if we could keep it centralized as much as possible. With
> this PR we end up with both a separate queue and a method that makes the Run
> operation behaves differently depending on the global DAP state (i.e. if
> we've send the configuration request).
The plan is to partially resolve the request and then completing the request
later on. for example.
with the launch argument, the new method will be
`optional<Response> DeferUntilConfig(
const Arguments &arguments, bool &defer_request)`
```cpp
std::optional<LaunchResponse> LaunchRequestHandler::DeferUntilConfig(
const LaunchRequestArguments &arguments, bool &defer_request) const {
// setups the target and initcommands.
if (LaunchResponse err = PreLaunch(arguments)) {
return err;
}
defer_request = !dap.configuration_done;
return std::nullopt;
}
```
since this it is then deferred it will then complete the remaining request
after the configuration is done. like so
```cpp
Error LaunchRequestHandler::Run(const LaunchRequestArguments &arguments) const {
if (Error err = dap.RunPreRunCommands())
return err;
if (Error err = LaunchProcess(arguments))
return err;
dap.RunPostRunCommands();
return Error::success();
}
```
The could potentially fix the breakpoints problem and also launch after
configuration. Not 100% sure this is the best way hence why I have not included
the commit.
https://github.com/llvm/llvm-project/pull/140260
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
