From bcfdfe4e5007867dcd2e80a36921dfc538aae9d9 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 26 Sep 2018 16:37:31 -0400 Subject: use the closure def-id in returns, but closure-base def-id in locals Using the `closure_base_def_id` indiscriminantely, as we were doing before, winds up "going wrong" if the closure type includes the `impl Trait` from the parent. The problem arises because the return value for closures is inferred and meant to treat the return type *opaquely*, so we don't want to be "desugaring" it into the underlying type. --- src/test/ui/impl-trait/closure-calling-parent-fn.rs | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 src/test/ui/impl-trait/closure-calling-parent-fn.rs (limited to 'src/test') diff --git a/src/test/ui/impl-trait/closure-calling-parent-fn.rs b/src/test/ui/impl-trait/closure-calling-parent-fn.rs new file mode 100644 index 00000000000..cb5f78bd6fc --- /dev/null +++ b/src/test/ui/impl-trait/closure-calling-parent-fn.rs @@ -0,0 +1,14 @@ +#![feature(nll)] + +// Regression test for #54593: the MIR type checker was going wrong +// when a closure returns the `impl Copy` from its parent fn. It was +// (incorrectly) replacing the `impl Copy` in its return type with the +// hidden type (`()`) but that type resulted from a recursive call to +// `foo` and hence is treated opaquely within the closure body. This +// resulted in a failed subtype relationship. +// +// run-pass + +fn foo() -> impl Copy { || foo(); } +fn bar() -> impl Copy { || bar(); } +fn main() { } -- cgit 1.4.1-3-g733a5