diff options
| author | Utkarsh Saxena <usx@google.com> | 2022-08-30 16:57:07 +0200 |
|---|---|---|
| committer | Utkarsh Saxena <usx@google.com> | 2022-09-02 12:30:52 +0200 |
| commit | e7eec38246560781e0a4020b19c7eb038a8c5655 (patch) | |
| tree | 6e9308e0405b903277744e45b5144569560c7239 /clang/unittests/libclang/LibclangTest.cpp | |
| parent | 51d4c7ceea61b5d83ba52398b5ca6d58d7551044 (diff) | |
| download | llvm-e7eec38246560781e0a4020b19c7eb038a8c5655.zip llvm-e7eec38246560781e0a4020b19c7eb038a8c5655.tar.gz llvm-e7eec38246560781e0a4020b19c7eb038a8c5655.tar.bz2 | |
[clang] Skip re-building lambda expressions in parameters to consteval fns.
As discussed in this [comment](https://github.com/llvm/llvm-project/issues/56183#issuecomment-1224331699),
we end up building the lambda twice: once while parsing the function calls and then again while handling the immediate invocation.
This happens specially during removing nested immediate invocation.
Eg: When we have another consteval function as the parameter along with this lambda expression. Eg: `foo(bar([]{}))`, `foo(bar(), []{})`
While removing such nested immediate invocations, we should not rebuild this lambda. (IIUC, rebuilding a lambda would always generate a new type which will never match the original type from parsing)
Fixes: https://github.com/llvm/llvm-project/issues/56183
Fixes: https://github.com/llvm/llvm-project/issues/51695
Fixes: https://github.com/llvm/llvm-project/issues/50455
Fixes: https://github.com/llvm/llvm-project/issues/54872
Fixes: https://github.com/llvm/llvm-project/issues/54587
Differential Revision: https://reviews.llvm.org/D132945
Diffstat (limited to 'clang/unittests/libclang/LibclangTest.cpp')
0 files changed, 0 insertions, 0 deletions