Document the peculiarity of the solver query a bit

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

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]

crates/ra_hir/src/ty/traits.rs

@@ -10,13 +10,15 @@ use self::chalk::{ToChalk, from_chalk};
 
 mod chalk;
 
+pub(crate) type Solver = chalk_solve::Solver;
+
 #[derive(Debug, Copy, Clone)]
 struct ChalkContext<'a, DB> {
     db: &'a DB,
     krate: Crate,
 }
 
-pub(crate) fn solver(_db: &impl HirDatabase, _krate: Crate) -> Arc<Mutex<chalk_solve::Solver>> {
+pub(crate) fn solver(_db: &impl HirDatabase, _krate: Crate) -> Arc<Mutex<Solver>> {
     // krate parameter is just so we cache a unique solver per crate
     let solver_choice = chalk_solve::SolverChoice::SLG { max_size: 10 };
     Arc::new(Mutex::new(solver_choice.into_solver()))
@@ -48,7 +50,7 @@ fn solve(
     goal: &chalk_ir::UCanonical<chalk_ir::InEnvironment<chalk_ir::Goal>>,
 ) -> Option<chalk_solve::Solution> {
     let context = ChalkContext { db, krate };
-    let solver = db.chalk_solver(krate);
+    let solver = db.solver(krate);
     let solution = solver.lock().unwrap().solve(&context, goal);
     eprintln!("solve({:?}) => {:?}", goal, solution);
     solution