You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
`GeneratorDatum` and `GeneratorWitnessDatum` are introduced, which
mirror `TyKind::Generator` and `TyKind::GeneratorWitness` in rustc.
We handle auto traits for `GeneratorDatum` using the existing
`constituent_types` method. For `GeneratorWitnessDatum`, we generate a
`forall<'a, 'b, ... 'z>` goal to reflect the fact that our lifetimes are
existentially bound.
Unresolved questions:
* The implementation of `GeneratorWitnessDatum` needs careful review -
I'm not certain that I fully understand how `Binders` works.
* The syntax implemented in `parser.lalrpop` can be bikesheeded. We
might want to use something other than `for<>` for the witness types,
to reflect that fact that we have existential rather than universal
quantification.
* The generator grammar only allows quantifying over liftimes for the
witness types - however, this gets lowered to a `Binders`, which
supports types and constants as well. Should we do anything else
to ensure we never end up with types/consts where they're not
expected?
* I added a test to ensure that we treat the witness lifetimes as
existentially quantified - for example, if we have
`for<'a, 'b> Foo<'a, 'b>`, we should only be able to use an auto
trait impl that is fully generic over lifetimes - e.g.
`impl<'a> Send for Foo<'a, 'b>` will not be used. I *believe*
that the test is showing this behavior - it ends up returning
region constraints that require `'a` and `'b` to outlive each other.
Since these are 'existential' lifetimes (which cannot be substituted),
this is an unsatisfiable constraint. However, I'm not sure where we
should be detecting that this is unsatisfiable.
0 commit comments