zygoloid wrote: It makes sense that the lambda and the enclosing function would both be imported, and we'd pick definitions from different TUs. Looking at the ASTReader code now, I don't see any real protection against that happening, and it would definitely lead to a broken AST.
In terms of how to fix this, perhaps: * When we try to import a closure type, if the context declaration is a function, then import a definition of that function. In this case, import *only* a declaration of the closure type. * When we import a lambda expression, import the definition of the closure type from the same source. * When we import a definition of a member of a closure type, use the definition from the same source that we used to import the definition of the closure type itself, rather than another declaration it's been merged with. That way, the definition of the closure type call operator and closure type captures that we import should come from the same source as the enclosing function, and hence should have the same declarations for local variables. In terms of how to do the above in practice, I'm not sure; I've not worked on the ASTReader code in quite a long time. But I think it should all be doable. https://github.com/llvm/llvm-project/pull/202248 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
