From 2e00214b3efbdfeefaa0fe9e8b8fd519de7adc35 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Wed, 17 Apr 2024 14:19:50 +0200 Subject: Merging upstream version 1.69.0+dfsg1. Signed-off-by: Daniel Baumann --- ...wo-projection-param-candidates-are-ambiguous.rs | 30 ++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 tests/ui/traits/new-solver/two-projection-param-candidates-are-ambiguous.rs (limited to 'tests/ui/traits/new-solver/two-projection-param-candidates-are-ambiguous.rs') diff --git a/tests/ui/traits/new-solver/two-projection-param-candidates-are-ambiguous.rs b/tests/ui/traits/new-solver/two-projection-param-candidates-are-ambiguous.rs new file mode 100644 index 000000000..cde2059ca --- /dev/null +++ b/tests/ui/traits/new-solver/two-projection-param-candidates-are-ambiguous.rs @@ -0,0 +1,30 @@ +// compile-flags: -Ztrait-solver=next + +// When we're solving `::Assoc = i32`, we actually first solve +// `::Assoc = _#1t`, then unify `_#1t` with `i32`. That goal +// with the inference variable is ambiguous when there are >1 param-env +// candidates. + +// We don't unify the RHS of a projection goal eagerly when solving, both +// for caching reasons and partly to make sure that we don't make the new +// trait solver smarter than it should be. + +// This is (as far as I can tell) a forwards-compatible decision, but if you +// make this test go from fail to pass, be sure you understand the implications! + +trait Foo { + type Assoc; +} + +trait Bar {} + +impl Bar for T where T: Foo {} + +fn needs_bar() {} + +fn foo + Foo>() { + needs_bar::(); + //~^ ERROR type annotations needed: cannot satisfy `T: Bar` +} + +fn main() {} -- cgit v1.2.3