summaryrefslogtreecommitdiff
path: root/lldb/test/API/python_api
diff options
context:
space:
mode:
authorSirraide <aeternalmail@gmail.com>2024-10-08 13:34:00 +0200
committerGitHub <noreply@github.com>2024-10-08 13:34:00 +0200
commitf01364ebc88d875fbfc0e00413538465aaa8a2b3 (patch)
tree5f5e41ceab9a3410f615a91520afc639c7942267 /lldb/test/API/python_api
parent235067b222e4734839b963e152b6554e20413d11 (diff)
[Clang] Instantiate the correct lambda call operator (#110446)
This is a fix for the following issue: when a lambda’s class type is merged across modules (e.g. because it is defined in a template in the GMF of some module `A`, and some other module `B` both imports `A` and has the same template in its GMF), then `getLambdaCallOperator()` might return the wrong operator (e.g. while compiling `B`, the lambda’s class type would be the one attached to `B`’s GMF, but the call operator ends up being the one attached to `A`’s GMF). This causes issues in situations where the call operator is in a template and accesses declarations in the surrounding context: when those declarations are instantated, a mapping is introduced from the original node in the template to that of the instantiation. If such an instantiation happens in `B`, and we then try to instantiate `A`’s call operator, any nodes in that call operator refer to declarations in the template in `A`, but the `LocalInstantiationScope` only contains mappings for declarations in `B`! This causes the following assertion (for godbolt links and more, see the issue below): ``` Assertion `isa<LabelDecl>(D) && "declaration not instantiated in this scope"' failed. ``` We now walk the redecl chain of the call operator to find the one that is in the same module as the record decl. This fixes #110401.
Diffstat (limited to 'lldb/test/API/python_api')
0 files changed, 0 insertions, 0 deletions