tree 9c206592fee8e54234dd735693e2b21bfc73407c
parent 846db94c667e534ec4886842030a8128186a51dd
parent 29e7ca940b781537605147455410914e8167f40f
author Pietro Albini <pietro@pietroalbini.org> 1544865452 +0100
committer GitHub <noreply@github.com> 1544865452 +0100
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJcFMasCRBK7hj4Ov3rIwAAdHIIAHyguC1qncdlCswHQoJY1WkY
 /3NP8qSTMLcDpGGG7vFXQSiOvHd79D7C9bVsrRG4Phbrzlq8SwKvSQv2XtVggSb4
 eTg2A8mUJ/q2XRrwf9tDUfvoOc/GVY6SdHuILM/4RrKC2Hno2xfpwyohlX57+fb3
 ghZmGFZuQ6Eajna+Fw4Gq5bKIvGD58TTUshigcycNEvc2ieOq1HwB45vDF+DOes1
 lPGMrtzbtIAKw+3EQlDeA+MtWZwykcYyWRWF299s7GL4rHv9kZo58BrRt2JSkbPF
 grL6vJtC4rx8qMk1ec1aufS3bsH+13tE2OYJBYitSbEyQ7jfMYftKSq+lBlbcXM=
 =5R4/
 -----END PGP SIGNATURE-----
 

Rollup merge of #56746 - pnkfelix:issue-56537-add-test-of-closure-using-region-from-containing-fn, r=nikomatsakis

Add test of current behavior (infer free region within closure body)

This behavior was previously not encoded in our test suite.

it is pretty important that we test this behavior. In particular, in #56537  I had proposed expanding the lifetime elision rules so that they would apply to some of the cases encoded in this test, which would cause them to start failing to compile successfully (because the lifetime attached to the return type would start being treated as connected to the lifetime on the input parameter to the lambda expression, which is explicitly *not* what the code wants in this particular case).

In other words, I am trying to ensure that anyone who tries such experiments with lifetime elision in the future quickly finds out why we don't support lifetime elision on lambda expressions (at least not in the naive manner described on #56537).