From ef77d8375130d12678d4b2316cc1708c90349dad Mon Sep 17 00:00:00 2001 From: Florian Diebold Date: Wed, 1 May 2019 17:13:33 +0200 Subject: 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 | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'crates/ra_hir/src/db.rs') 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>; + fn solver(&self, krate: Crate) -> Arc>; } #[test] -- cgit v1.2.3