1//! Zed's debugger data layer is implemented in terms of 3 concepts:
 2//! - DAP store - that knows about all of the available debug sessions.
 3//! - Debug sessions - that bear responsibility of communicating with debug adapters and managing the state of each individual session.
 4//!   For the most part it is agnostic over the communication layer (it'll use RPC for peers and actual DAP requests for the host).
 5//! - Breakpoint store - that knows about all breakpoints set for a project.
 6//!
 7//! There are few reasons for this divide:
 8//! - Breakpoints persist across debug sessions and they're not really specific to any particular session. Sure, we have to send protocol messages for them
 9//!   (so they're a "thing" in the protocol), but we also want to set them before any session starts up.
10//! - Debug clients are doing the heavy lifting, and this is where UI grabs all of it's data from. They also rely on breakpoint store during initialization to obtain
11//!   current set of breakpoints.
12//! - Since DAP store knows about all of the available debug sessions, it is responsible for routing RPC requests to sessions. It also knows how to find adapters for particular kind of session.
13
14pub mod breakpoint_store;
15pub mod dap_command;
16pub mod dap_store;
17pub mod locators;
18mod memory;
19pub mod session;
20
21#[cfg(any(feature = "test-support", test))]
22pub mod test;
23pub use memory::MemoryCell;