llvm-project
llvm-project copied to clipboard
llvm
Templated Lambda with requires clause defined inside concept crash when instantiated constraints.
As reported here: https://reviews.llvm.org/D126907 and reproduced here: https://cute.godbolt.org/z/Prh6xsesz
Lambdas that are defined inside of a concept and have a requires clause crash while instantiating their requires clause, because we don't add the concept's template arguments to the MultiLevelTemplateArgumentList.
Typically, we 'rebuild' the template argument lists by walking back through the instantiated Decls. However in this case, the lambda is defined inside of a ConceptSpecializationExpr, which doesn't really exist inside of a decl-context-tree. I'll have to figure out how to make the Expr a context for the purposes of rebuilding these template argument lists.
This gets more troublesome with nested lambdas, and it isn't clear when we might be off trying to instantiate a DIFFERENT dependency (that is, if the lambda's requires clause causes a different requires clause, outside of the concept to be evaluated).
I'm still looking at this, but want to capture this before the weekend.
That sounds suspiciously close to https://github.com/llvm/llvm-project/issues/56154 which is about concept normalization 'forgetting' the concept template arguments.
I don't believe this is related at all, the fact pattern is a lambda with a requires clause defined inside a concept, which causes the template arguments to not be correct when checking the lambda's requires clause.
This is going to requite a new Decl kind for a concept-specialization, which I was working on friday.
As an update, I've come up with a patch that is not quite ready for review (I have a ton of TODOs) that proves out my idea of splitting ConceptSpecializationExpr into ConceptSpecializationDecl and ConceptSpecializationExpr. The above reproducer works perfectly with it.
Put up a review here to have the code-owner take a look: https://reviews.llvm.org/D136451 but others are welcome to it as well.