diff options
author | Sirraide <aeternalmail@gmail.com> | 2024-10-11 20:03:43 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-10-11 20:03:43 +0200 |
commit | 48bda00b281a432d6de5e5e5dde6c5d66b992ac8 (patch) | |
tree | 99b7f1000fb388bb9e39e85d0a434c0f8c3b7f78 /llvm/lib/Analysis/ModuleSummaryAnalysis.cpp | |
parent | 2aa1dbf9c92e3b27954ba9166c927616625073e8 (diff) | |
download | llvm-48bda00b281a432d6de5e5e5dde6c5d66b992ac8.zip llvm-48bda00b281a432d6de5e5e5dde6c5d66b992ac8.tar.gz llvm-48bda00b281a432d6de5e5e5dde6c5d66b992ac8.tar.bz2 |
[Clang] [Sema] Don't crash on unexpanded pack in invalid block literal (#110762)
Consider #109148:
```c++
template <typename ...Ts>
void f() {
[] {
(^Ts);
};
}
```
When we encounter `^Ts`, we try to parse a block and subsequently call
`DiagnoseUnexpandedParameterPack()` (in `ActOnBlockArguments()`), which
sees `Ts` and sets `ContainsUnexpandedParameterPack` to `true` in the
`LambdaScopeInfo` of the enclosing lambda. However, the entire block is
subsequently discarded entirely because it isn’t even syntactically
well-formed. As a result, `ContainsUnexpandedParameterPack` is `true`
despite the lambda’s body no longer containing any unexpanded packs,
which causes an assertion the next time
`DiagnoseUnexpandedParameterPack()` is called.
This pr moves handling of unexpanded parameter packs into
`CapturingScopeInfo` instead so that the same logic is used for both
blocks and lambdas. This fixes this issue since the
`ContainsUnexpandedParameterPack` flag is now part of the block (and
before that, its `CapturingScopeInfo`) and no longer affects the
surrounding lambda directly when the block is parsed. Moreover, this
change makes blocks actually usable with pack expansion.
This fixes #109148.
Diffstat (limited to 'llvm/lib/Analysis/ModuleSummaryAnalysis.cpp')
0 files changed, 0 insertions, 0 deletions