[Lldb-commits] [clang] [clang-tools-extra] [lldb] [clang] Reland: Instantiate alias templates with sugar (PR #101858)
Matheus Izvekov via lldb-commits
lldb-commits at lists.llvm.org
Sun Aug 11 15:58:39 PDT 2024
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
More information about the lldb-commits
mailing list