/// All functions are cheap to call, as they grab current state of the debug session and schedule refreshing on a background
/// thread if that state is outdated.
pub fn modules(&mut self, cx: &mut Context<Self>) -> &[Module] {
 /// Kick off a fresh request to a DAP for modules list if we don't have an up-to-date state.
 /// This is a no-op in case we've ran that request already. In case we did not, it kicks off a background task.
 self.fetch(
 /// We cache request results based on it's arguments. `Modules` request does not take any arguments
 dap_command::ModulesCommand,
 /// Callback invoked with the result of a request.
 |this, result, cx| {
 let Some(result) = result.log_err() else {
 return;
 };
 
 this.modules = result;
 cx.emit(SessionEvent::Modules);
 cx.notify();
 },
 cx,
 );
 
 /// Returns a current list of modules; it might be outdated at the time the new request is underway,
 /// but once it is done, the return value of this function will reflect that.
 &self.modules
}

/// This function is called from the Module list render function in the UI layer whenever the data layer invalidates the module list state.
fn schedule_rebuild(&mut self, cx: &mut Context<Self>) {
 /// Setting the task drops any current work in progress that is out of date
 self._rebuild_task = Some(cx.spawn(async move |this, cx| {
 this.update(cx, |this, cx| {
 /// The UI layer queries the data layer for modules and clones the data
 let modules = this
 .session
 .update(cx, |session, cx| session.modules(cx).to_owned());
 this.entries = modules;
 cx.notify();
 })
 .ok();
 }));
}

 /// Returns the debug adapter binary for the specified adapter name and configuration.
 fn get_dap_binary(
 &mut self,
 _adapter_name: String,
 _config: DebugTaskDefinition,
 _user_provided_debug_adapter_path: Option<String>,
 _worktree: &Worktree,
 ) -> Result<DebugAdapterBinary, String> {
 Err("`get_dap_binary` not implemented".to_string())
 }
 
 /// Determines whether the specified adapter configuration should *launch* a new debuggee process
 /// or *attach* to an existing one. This function should not perform any further validation (outside of determining the kind of a request).
 /// This function should return an error when the kind cannot be determined (rather than fall back to a known default).
 fn dap_request_kind(
 &mut self,
 _adapter_name: String,
 _config: serde_json::Value,
 ) -> Result<StartDebuggingRequestArgumentsRequest, String> {
 Err("`dap_request_kind` not implemented".to_string())
 }
 /// Converts a high-level definition of a debug scenario (originating in a new session UI) to a "low-level" configuration suitable for a particular adapter.
 ///
 /// In layman's terms: given a program, list of arguments, current working directory and environment variables,
 /// create a configuration that can be used to start a debug session.
 fn dap_config_to_scenario(&mut self, _config: DebugConfig) -> Result<DebugScenario, String> {
 Err("`dap_config_to_scenario` not implemented".to_string())
 }
 
 /// Locators are entities that convert a Zed task into a debug scenario.
 ///
 /// They can be provided even by extensions that don't provide a debug adapter.
 /// For all tasks applicable to a given buffer, Zed will query all locators to find one that can turn the task into a debug scenario.
 /// A converted debug scenario can include a build task (it shouldn't contain any configuration in such case); a build task result will later
 /// be resolved with [`Extension::run_dap_locator`].
 ///
 /// To work through a real-world example, take a `cargo run` task and a hypothetical `cargo` locator:
 /// 1. We may need to modify the task; in this case, it is problematic that `cargo run` spawns a binary. We should turn `cargo run` into a debug scenario with
 /// `cargo build` task. This is the decision we make at `dap_locator_create_scenario` scope.
 /// 2. Then, after the build task finishes, we will run `run_dap_locator` of the locator that produced the build task to find the program to be debugged. This function
 /// should give us a debugger-agnostic configuration for launching a debug target (that we end up resolving with [`Extension::dap_config_to_scenario`]). It's almost as if the user
 /// found the artifact path by themselves.
 ///
 /// Note that you're not obliged to use build tasks with locators. Specifically, it is sufficient to provide a debug configuration directly in the return value of
 /// `dap_locator_create_scenario` if you're able to do that. Make sure to not fill out `build` field in that case, as that will prevent Zed from running second phase of resolution in such case.
 /// This might be of particular relevance to interpreted languages.
 fn dap_locator_create_scenario(
 &mut self,
 _locator_name: String,
 _build_task: TaskTemplate,
 _resolved_label: String,
 _debug_adapter_name: String,
 ) -> Option<DebugScenario> {
 None
 }
 
 /// Runs the second phase of locator resolution.
 /// See [`Extension::dap_locator_create_scenario`] for a hefty comment on locators.
 fn run_dap_locator(
 &mut self,
 _locator_name: String,
 _build_task: TaskTemplate,
 ) -> Result<DebugRequest, String> {
 Err("`run_dap_locator` not implemented".to_string())
 }