Merge #5124

5124: (Partially) fix handling of type params depending on type params r=matklad a=flodiebold

If the first type parameter gets inferred, that's still not handled correctly; it'll require some more refactoring: E.g. if we have `Thing<T, F=fn() -> T>` and then instantiate `Thing<_>`, that gets turned into `Thing<_, fn() -> _>` before the `_` is instantiated into a type variable -- so afterwards, we have two type variables without any connection to each other.

Co-authored-by: Florian Diebold <[email protected]>

1 files changed, 45 insertions, 0 deletions

diff --git a/crates/ra_hir_ty/src/tests/simple.rs b/crates/ra_hir_ty/src/tests/simple.rs
index cd919466f..5e3f2bd3c 100644
--- a/crates/ra_hir_ty/src/tests/simple.rs
+++ b/crates/ra_hir_ty/src/tests/simple.rs
@@ -2152,3 +2152,48 @@ fn test() {
     "###
     );
 }
+
+#[test]
+fn generic_default_depending_on_other_type_arg() {
+    assert_snapshot!(
+        infer(r#"
+struct Thing<T = u128, F = fn() -> T> { t: T }
+
+fn test(t1: Thing<u32>, t2: Thing) {
+    t1;
+    t2;
+    Thing::<_> { t: 1u32 };
+}
+"#),
+        // FIXME: the {unknown} is a bug
+        @r###"
+    56..58 't1': Thing<u32, fn() -> u32>
+    72..74 't2': Thing<u128, fn() -> u128>
+    83..130 '{     ...2 }; }': ()
+    89..91 't1': Thing<u32, fn() -> u32>
+    97..99 't2': Thing<u128, fn() -> u128>
+    105..127 'Thing:...1u32 }': Thing<u32, fn() -> {unknown}>
+    121..125 '1u32': u32
+    "###
+    );
+}
+
+#[test]
+fn generic_default_depending_on_other_type_arg_forward() {
+    assert_snapshot!(
+        infer(r#"
+struct Thing<F = fn() -> T, T = u128> { t: T }
+
+fn test(t1: Thing) {
+    t1;
+}
+"#),
+        // the {unknown} here is intentional, as defaults are not allowed to
+        // refer to type parameters coming later
+        @r###"
+    56..58 't1': Thing<fn() -> {unknown}, u128>
+    67..78 '{     t1; }': ()
+    73..75 't1': Thing<fn() -> {unknown}, u128>
+    "###
+    );
+}