From 957939292ec9038f139bd10e093e9673609eea04 Mon Sep 17 00:00:00 2001 From: Josh Mcguigan Date: Tue, 16 Mar 2021 08:45:46 -0700 Subject: completion relevance consider if types can be unified --- crates/ide_completion/src/render.rs | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) (limited to 'crates/ide_completion/src/render.rs') diff --git a/crates/ide_completion/src/render.rs b/crates/ide_completion/src/render.rs index 9ce49074f..12453f889 100644 --- a/crates/ide_completion/src/render.rs +++ b/crates/ide_completion/src/render.rs @@ -314,7 +314,8 @@ fn compute_exact_type_match(ctx: &CompletionContext, completion_ty: &hir::Type) Some(expected_type) => { // We don't ever consider unit type to be an exact type match, since // nearly always this is not meaningful to the user. - completion_ty == expected_type && !expected_type.is_unit() + (completion_ty == expected_type || expected_type.could_unify_with(completion_ty)) + && !expected_type.is_unit() } None => false, } @@ -1353,4 +1354,34 @@ fn foo(f: Foo) { let _: &u32 = f.b$0 } "#]], ); } + + #[test] + fn generic_enum() { + check_relevance( + r#" +enum Foo { A(T), B } +// bar() should not be an exact type match +// because the generic parameters are different +fn bar() -> Foo { Foo::B } +// FIXME baz() should be an exact type match +// because the types could unify, but it currently +// is not. This is due to the T here being +// TyKind::Placeholder rather than TyKind::Missing. +fn baz() -> Foo { Foo::B } +fn foo() { + let foo: Foo = Foo::B; + let _: Foo = f$0; +} +"#, + expect![[r#" + ev Foo::A(…) [type] + ev Foo::B [type] + lc foo [type+local] + en Foo [] + fn baz() [] + fn bar() [] + fn foo() [] + "#]], + ); + } } -- cgit v1.2.3