Handle cycles in RPITIT computation

Cycles can occur in malformed code (this is only a conjecture) or from Chalk bugs (for this I have a test).

Author: ChayimFriedman2

crates/hir-ty/src/chalk_db.rs

@@ -13,7 +13,9 @@ use chalk_ir::{
     cast::{Cast, Caster},
     fold::shift::Shift,
 };
-use chalk_solve::rust_ir::{self, AssociatedTyDatumBound, OpaqueTyDatumBound, WellKnownTrait};
+use chalk_solve::rust_ir::{
+    self, AssociatedTyDatumBound, AssociatedTyValueBound, OpaqueTyDatumBound, WellKnownTrait,
+};
 
 use base_db::Crate;
 use hir_def::{
@@ -1008,6 +1010,31 @@ pub(crate) fn associated_ty_value_query(
     }
 }
 
+/// We need cycle recovery because RPITITs can cause cycles.
+pub(crate) fn associated_ty_value_cycle(
+    db: &dyn HirDatabase,
+    krate: Crate,
+    id: AssociatedTyValueId,
+) -> Arc<AssociatedTyValue> {
+    match from_assoc_type_value_id(db, id) {
+        AnyImplAssocType::Normal(type_alias) => {
+            type_alias_associated_ty_value(db, krate, type_alias)
+        }
+        AnyImplAssocType::Rpitit(assoc_type_id) => {
+            let assoc = assoc_type_id.loc(db);
+            let trait_assoc = assoc.trait_assoc.loc(db);
+            Arc::new(AssociatedTyValue {
+                associated_ty_id: to_assoc_type_id_rpitit(assoc.trait_assoc),
+                impl_id: assoc.impl_id.to_chalk(db),
+                value: trait_assoc
+                    .bounds
+                    .as_ref()
+                    .map(|_| AssociatedTyValueBound { ty: TyKind::Error.intern(Interner) }),
+            })
+        }
+    }
+}
+
 fn rpitit_associated_ty_value(
     db: &dyn HirDatabase,
     assoc_type_id: RpititImplAssocTyId,

crates/hir-ty/src/db.rs

@@ -290,6 +290,7 @@ pub trait HirDatabase: DefDatabase + std::fmt::Debug {
     fn variances_of(&self, def: GenericDefId) -> Option<Arc<[crate::variance::Variance]>>;
 
     #[salsa::invoke(chalk_db::associated_ty_value_query)]
+    #[salsa::cycle(cycle_result = chalk_db::associated_ty_value_cycle)]
     fn associated_ty_value(
         &self,
         krate: Crate,

crates/hir-ty/src/tests/traits.rs

@@ -5141,7 +5141,10 @@ impl<T, U> Trait<(Foo<()>, U)> for Foo<T> {}
 }
 
 #[test]
-fn check_foo() {
+fn rpitit_cycle() {
+    // This shouldn't cause a cycle, but it does due to Chalk shortcomings. It should be
+    // fixed when we switch to the new trait solver. However, I believe it will still possible
+    // to cause cycles with malformed code, so we still need the cycle handlers.
     check_rpitit(
         r#"
 //- minicore: future, send, sized
@@ -5153,6 +5156,10 @@ trait DesugaredAsyncTrait {
 
 impl DesugaredAsyncTrait for () {}
     "#,
-        expect![[r#""#]],
+        expect![[r#"
+            type __foo_rpitit: Future<Output = usize> + Send;
+
+            type __foo_rpitit = {unknown};
+        "#]],
     );
 }