Fixed remaining references to AnalysisChange (now: Change)

(The type was renamed/moved in 8716c4cec3)
This commit is contained in:
Vincent Esche 2021-02-28 12:57:41 +01:00
parent 7ed2da652d
commit c4e2f32d73
4 changed files with 8 additions and 8 deletions

View file

@ -19,7 +19,7 @@ pub struct Change {
impl fmt::Debug for Change {
fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result {
let mut d = fmt.debug_struct("AnalysisChange");
let mut d = fmt.debug_struct("Change");
if let Some(roots) = &self.roots {
d.field("roots", roots);
}

View file

@ -32,7 +32,7 @@ struct RootChange {
impl fmt::Debug for RootChange {
fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result {
fmt.debug_struct("AnalysisChange")
fmt.debug_struct("RootChange")
.field("added", &self.added.len())
.field("removed", &self.removed.len())
.finish()

View file

@ -1,7 +1,7 @@
//! This modules defines type to represent changes to the source code, that flow
//! from the server to the client.
//!
//! It can be viewed as a dual for `AnalysisChange`.
//! It can be viewed as a dual for `Change`.
use std::{
collections::hash_map::Entry,

View file

@ -65,11 +65,11 @@ Next, let's talk about what the inputs to the `Analysis` are, precisely.
Rust Analyzer never does any I/O itself, all inputs get passed explicitly via
the `AnalysisHost::apply_change` method, which accepts a single argument, a
`AnalysisChange`. [`AnalysisChange`] is a builder for a single change
`Change`. [`Change`] is a builder for a single change
"transaction", so it suffices to study its methods to understand all of the
input data.
[`AnalysisChange`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ide_api/src/lib.rs#L119-L167
[`Change`]: https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/base_db/src/change.rs#L14-L89
The `(add|change|remove)_file` methods control the set of the input files, where
each file has an integer id (`FileId`, picked by the client), text (`String`)
@ -158,7 +158,7 @@ it should be possible to dynamically reconfigure it later without restart.
[main_loop.rs#L62-L70](https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_lsp_server/src/main_loop.rs#L62-L70)
The [`ProjectModel`] we get after this step is very Cargo and sysroot specific,
it needs to be lowered to get the input in the form of `AnalysisChange`. This
it needs to be lowered to get the input in the form of `Change`. This
happens in [`ServerWorldState::new`] method. Specifically
* Create a `SourceRoot` for each Cargo package and sysroot.
@ -175,7 +175,7 @@ of the main loop, just like any other change. Here's where we handle:
* [File system changes](https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_lsp_server/src/main_loop.rs#L194)
* [Changes from the editor](https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_lsp_server/src/main_loop.rs#L377)
After a single loop's turn, we group the changes into one `AnalysisChange` and
After a single loop's turn, we group the changes into one `Change` and
[apply] it. This always happens on the main thread and blocks the loop.
[apply]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_lsp_server/src/server_world.rs#L216
@ -256,7 +256,7 @@ database.
[`RootDatabase`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ide_api/src/db.rs#L88-L134
Salsa input queries are defined in [`FilesDatabase`] (which is a part of
`RootDatabase`). They closely mirror the familiar `AnalysisChange` structure:
`RootDatabase`). They closely mirror the familiar `Change` structure:
indeed, what `apply_change` does is it sets the values of input queries.
[`FilesDatabase`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/base_db/src/input.rs#L150-L174