The basic summary is what I said -- there is an "approximate" check that computes the "generator witness", which is a superset of the data that is really needed.
I'll maybe leave some comments on #57017, the relevant code is in generator_interior.rs, and particularly this part of it. It's presently pretty conservative -- it assumes that the result of each intermediate expression may be stored as long as the enclosing temporary scope.
I think we could probably make that more precise by modified the expr-use-visitor and using that to be smarter. This would certainly fix the example in question, though there'd probably still be a measure of imprecision involved. I didn't quite get to seeing clearly the change, have to think on it a bit.
I want to compute the generator interior on MIR, which should help with those cases
@Zoxc I don't think you can necessarily do that -- in particular, we need to know this information during the typeck phase, in order to compute (e.g.) whether something is
Further, right now, type checking of the generator is intermingled with type-checking of the surrounding function (this is generally true for closures), so we can't be sure to be able to construct the MIR for the generator until type-checking of the overall fn is complete, and it seems to me that this could depend on whether the generator is
(We could potentially do some sort of best effort thing, and error around cycles, but I'm not sure how I feel about that, I'd like to at least explore if we can compute a better approximation of live data first)
We currently generate an error if we try to infer the generator interior of a generator, but don't know all the types inside. That should leave us room to construct MIR just for the generator in the future
Which error are you referring to?
@nikomatsakis ^this convo seems relevant to the other ongoing thread
cc @Giles Cope
@Taylor Cramer yes I was going to say that :)
when I mentioned "I have a hunch what the problem is", I was thinking of this...