https://bugs.llvm.org/show_bug.cgi?id=41909 describes an issue in which
a generic lambda that takes a dependent argument auto set causes the
template instantiation machinery for coroutine body statements to crash
with an ICE. The issue is two-fold:
- The paths taken by the template instantiator contain several asserts that the coroutine promise must not have a dependent type.
- The template instantiator unconditionally builds corotuine statements that depend on the promise type, which cannot be dependent.
To work around the issue, prevent the template instantiator from building
dependent coroutine statements if the coroutine promise type is dependent.
Since we only expect this to occur in the case of a generic lambda, limit
the workaround behavior to just that case.
This assert doesn't seem correct to me; there's no reason to assume we have a generic lambda here. (A non-generic lambda inside a generic lambda, whose parameter types are dependent on the generic lambda's parameters, would hit exactly the same issue, for instance.)
Generally we should write the template instantiation code so it could be used to substitute into the definition of a function template to produce another function template, even if we happen to never call it that way right now (though deduction guide processing gets pretty close). The right thing to do here is to either substitute into the representation we already formed (building a dependent representation if it's still dependent and a non-dependent representation otherwise) or to rebuild the coroutine body from scratch (again, creating a dependent representation if the result is still dependent).