Extract LSP state in own object #358
Conversation
crates/ark/src/lsp/state.rs
Outdated
| pub struct Workspace { | ||
| pub folders: Vec<Url>, | ||
| } | ||
|
|
||
| impl Default for Workspace { | ||
| fn default() -> Self { | ||
| Self { | ||
| folders: Default::default(), | ||
| } |
There was a problem hiding this comment.
While we are here, any preference for default() vs new() for Workspace? I probably would have implemented a new() method that set folders: Vec::new(). No super strong opinion, but sometimes I have disagreed with what default() implementations of the underlying components ended up being, so now I guess I prefer new()
There was a problem hiding this comment.
I think it makes sense to start with an empty workspace.
Regarding new vs default, a nice property of the former is that it allows algorithms based on mem::take() (not that we are likely to need this here). It also makes it easier to wrap around a constructor and override only some of the fields.
I agree that it's a bit ambiguous when to use one versus the other.
lionel-
force-pushed
the
feature/lsp-state
branch
from
6e31619 to
ed7d32f
Compare
Branched from #357.
This PR starts the work of gathering all LSP inputs to a new
WorldStatestruct. This data structure will eventually be a pure value without any interior mutability (e.g. no DashMap of Documents). The goal is that if you take a clone of it, you can send it off to a long-running background task without running the risk of invalidated assumptions due to input mutation after an LSP update.Progress towards posit-dev/positron#3181 (Incremental and cancellable computations with salsa): In the longer term this could serve as the source of root Salsa inputs for incremental computation. Querying an outdated Salsa input would cancel the background task with a special unwinding panic.