mizvekov wrote: > It is not only valuable to external resugarers. Another point that warrants > an introduction of it is for unevaluated lambdas. These lambdas e.g. > appearing as part of the `using Alias = decltype(lambda)` could carry a > requires expression and thus evaluating it requires the recovery of the > instantiating template arguments for the type alias, which isn't a quite > natural thing without such a Decl. I have improved some of these situations > through an on-stack InstantiatingTemplate to help to inspect the template > arguments; however, that approach is somewhat cumbersome and still couldn't > extend to other scenarios e.g. mangling these lambdas. (#97024. We need a > correct DeclContext for the lambda, yet a `TypeAliasTemplateDecl` isn't a > DeclContext, unfortunately.)
So in clang we have taken a different approach, in order to not sacrifice template type alias performance, we instead put a `Decl` context reference in templated declarations that can appear within a template type alias pattern, such as lambdas and blocks. The idea is a tradeoff where template type alias, which are very light weight, don't get the big performance hit they would otherwise if they had a per-specialization declaration. But we get a slight performance hit on Lambdas instead, but these are much more heavy weight and need the declcontext anyway for other reasons. The other tradeoff is increased implementation complexity. See for example CXXRecordDecl's `getLambdaContextDecl` function. Unfortunately there is an issue where we currently only store this lambda context when we need it for mangling reasons, but there are other reasons to depend on it as well, and code in clang currently makes the incorrect assumption that it will always be available when needed. I am working on a patch to fix that. https://github.com/llvm/llvm-project/pull/101858 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
