diff options
| author | Younan Zhang <zyn7109@gmail.com> | 2024-08-27 09:25:53 +0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-08-27 09:25:53 +0800 |
| commit | b412ec5d3924c7570c2c96106f95a92403a4e09b (patch) | |
| tree | 03b9f04a2ce0b7023e7bfa03dde9bb0f41a994d9 /lldb/source/Plugins/ScriptInterpreter/Python | |
| parent | 87157ab0f672a4755d231494b2162939811a014f (diff) | |
| download | llvm-b412ec5d3924c7570c2c96106f95a92403a4e09b.zip llvm-b412ec5d3924c7570c2c96106f95a92403a4e09b.tar.gz llvm-b412ec5d3924c7570c2c96106f95a92403a4e09b.tar.bz2 | |
[Clang][Sema] Revisit the fix for the lambda within a type alias template decl (#89934)
In the last patch #82310, we used template depths to tell if such alias
decls contain lambdas, which is wrong because the lambda can also appear
as a part of the default argument, and that would make
`getTemplateInstantiationArgs` provide extra template arguments in
undesired contexts. This leads to issue #89853.
Moreover, our approach
for https://github.com/llvm/llvm-project/issues/82104 was sadly wrong.
We tried to teach `DeduceReturnType` to consider alias template
arguments; however, giving these arguments in the context where they
should have been substituted in a `TransformCallExpr` call is never
correct.
This patch addresses such problems by using a `RecursiveASTVisitor` to
check if the lambda is contained by an alias `Decl`, as well as
twiddling the lambda dependencies - we should also build a dependent
lambda expression if the surrounding alias template arguments were
dependent.
Fixes #89853
Fixes #102760
Fixes #105885
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python')
0 files changed, 0 insertions, 0 deletions
