Document the peculiarity of the solver query a bit

Also remove the only remaining mention of chalk outside of the ty::traits
module.

1 files changed, 6 insertions, 1 deletions

diff --git a/crates/ra_hir/src/db.rs b/crates/ra_hir/src/db.rs
index b2c4fccf2..8aaf0375a 100644
--- a/crates/ra_hir/src/db.rs
+++ b/crates/ra_hir/src/db.rs
@@ -153,9 +153,14 @@ pub trait HirDatabase: DefDatabase {
     #[salsa::invoke(crate::ty::traits::impls_for_trait)]
     fn impls_for_trait(&self, krate: Crate, trait_: Trait) -> Arc<[ImplBlock]>;
 
+    /// This provides the Chalk trait solver instance. Because Chalk always
+    /// works from a specific crate, this query is keyed on the crate; and
+    /// because Chalk does its own internal caching, the solver is wrapped in a
+    /// Mutex and the query is marked volatile, to make sure the cached state is
+    /// thrown away when input facts change.
     #[salsa::invoke(crate::ty::traits::solver)]
     #[salsa::volatile]
-    fn chalk_solver(&self, krate: Crate) -> Arc<Mutex<chalk_solve::Solver>>;
+    fn solver(&self, krate: Crate) -> Arc<Mutex<crate::ty::traits::Solver>>;
 }
 
 #[test]