-
Notifications
You must be signed in to change notification settings - Fork 11.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple immediate invocation expression-statements of lambda expressions should be constant expressions #50455
Multiple immediate invocation expression-statements of lambda expressions should be constant expressions #50455
Comments
@llvm/issue-subscribers-clang-frontend |
@usx95 did you consider backporting to Clang 15.x? Seems like a pretty safe fix. |
/cherry-pick e7eec38 |
Error: Command failed due to missing milestone. |
/cherry-pick e7eec38 |
Failed to cherry-pick: e7eec38 https://github.com/llvm/llvm-project/actions/runs/3002632023 Please manually backport the fix and push it to your github fork. Once this is done, please add a comment like this:
|
…l fns. As discussed in this [comment](llvm#56183 (comment)), 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: llvm#56183 Fixes: llvm#51695 Fixes: llvm#50455 Fixes: llvm#54872 Fixes: llvm#54587 Differential Revision: https://reviews.llvm.org/D132945 (cherry picked from commit e7eec38)
/branch usx95/llvm-project/release/15.x |
/pull-request llvm/llvm-project-release-prs#145 |
…l fns. As discussed in this [comment](llvm/llvm-project#56183 (comment)), 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: llvm/llvm-project#56183 Fixes: llvm/llvm-project#51695 Fixes: llvm/llvm-project#50455 Fixes: llvm/llvm-project#54872 Fixes: llvm/llvm-project#54587 Differential Revision: https://reviews.llvm.org/D132945 (cherry picked from commit e7eec38)
…l fns. As discussed in this [comment](llvm/llvm-project#56183 (comment)), 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: llvm/llvm-project#56183 Fixes: llvm/llvm-project#51695 Fixes: llvm/llvm-project#50455 Fixes: llvm/llvm-project#54872 Fixes: llvm/llvm-project#54587 Differential Revision: https://reviews.llvm.org/D132945 (cherry picked from commit e7eec38246560781e0a4020b19c7eb038a8c5655)
Extended Description
See https://godbolt.org/z/YqG7P977v.
The text was updated successfully, but these errors were encountered: