-
Notifications
You must be signed in to change notification settings - Fork 10.9k
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
ICE: passing the result of a consteval function to another consteval function is crashing Clang #51695
Comments
This doesn't work either: void test() { |
I can confirm this is happening on trunk. The full stack trace is: Clang++: /root/llvm-project/clang/lib/Sema/SemaExpr.cpp:16774: void RemoveNestedImmediateInvocation(clang::Sema&, clang::Sema::ExpressionEvaluationContextRecord&, llvm::SmallVectorTemplateCommon<llvm::PointerIntPair<clang::ConstantExpr*, 1>, void>::reverse_iterator): Assertion `Res.isUsable()' failed.
#0 0x000055fa452b23ff PrintStackTraceSignalHandler(void*) Signals.cpp:0:0 |
Reduced consteval bool zero() { return false; }
template <typename F>
consteval bool foo(bool, F) {
return true;
}
bool test() {
return foo(zero(), []() { return true; });
} Moving the lambda to a |
@llvm/issue-subscribers-clang-frontend |
@llvm/issue-subscribers-c-20 |
…l fns. As discussed in this [comment](#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: #56183 Fixes: #51695 Fixes: #50455 Fixes: #54872 Fixes: #54587 Differential Revision: https://reviews.llvm.org/D132945
…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)
…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)
Godbolt
Extended Description
=== version
$ clang++.exe --version
clang version 14.0.0 (https://github.com/llvm/llvm-project abdb82b)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Dev\LLVM\bin
=== repro
$ type ice.cpp
template
struct type_t {};
template <typename...>
struct list_t {};
template <typename T, typename... Ts>
consteval auto pop_front(list_t<T, Ts...>) -> auto {
return list_t<Ts...>{};
}
template <typename... Ts, typename F>
consteval auto apply(list_t<Ts...>, F fn) -> auto {
return fn(type_t{}...);
}
void test() {
apply(
pop_front(list_t<char, char>{}),
[]<typename... Us>(type_t...) {
return false;
});
}
$ clang++.exe -std=c++20 ice.cpp
ice.cpp:18:3: warning: expression result unused [-Wunused-value]
apply(
^~~~~~
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run scri
pt.
Stack dump:
0. Program arguments: C:\Dev\LLVM\bin\clang++.exe -cc1 -triple x86_64-pc-windows-msvc19.29.30037 -emit-obj -mrelax-all -m
incremental-linker-compatible --mrelax-relocations -disable-free -disable-llvm-verifier -discard-value-names -main-file-name ice.c
pp -mrelocation-model pic -pic-level 2 -mframe-pointer=none -fmath-errno -fno-rounding-math -mconstructor-aliases -funwind-tables=
2 -target-cpu x86-64 -tune-cpu generic -fcoverage-compilation-dir=C:\Users\IVAN\Desktop\peg\build -resource-dir C:\Dev\LLVM
\lib\clang\14.0.0 -internal-isystem C:\Dev\LLVM\lib\clang\14.0.0\include -internal-isystem "C:\Program Files (x86)\Micr
osoft Visual Studio 2019\VC\Tools\MSVC\14.29.30037\ATLMFC\include" -internal-isystem "C:\Program Files (x86)\Microsoft Vis
ual Studio 2019\VC\Tools\MSVC\14.29.30037\include" -internal-isystem "C:\Program Files (x86)\Windows Kits\10\include\10.
0.19041.0\ucrt" -internal-isystem "C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared" -internal-isystem "C
:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um" -internal-isystem "C:\Program Files (x86)\Windows Kits\10
\include\10.0.19041.0\winrt" -internal-isystem "C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\cppwinrt" -std
=c++20 -fdeprecated-macro -fdebug-compilation-dir=C:\Users\IVAN\Desktop\peg\build -ferror-limit 19 -fmessage-length=130 -fno-
use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.29.30037 -fdelayed-template-parsing -fno-implicit-
modules -fcxx-exceptions -fexceptions -fcolor-diagnostics -faddrsig -o C:\Users\IVAN\AppData\Local\Temp\ice-1a857b.o -x c++
ice.cpp
0x00007FF65B2A6AFA (0x0000000000000000 0x0000000000000000 0x0000000000000068 0x0000000000000000)
0x00007FF65B27D237 (0x0000003ABCD8B890 0x00000191E1C45940 0x00000191E1C45940 0x00007FF65CABE420)
0x00007FF65B278925 (0x00008A62DA3A4C5B 0x00000191E1BE2140 0x0000000000000100 0x0000000000000000)
0x00007FF65B2784F1 (0x00008A62DA3A4401 0x00007FF600000000 0x0000000000000100 0x00000191E1BECD10)
0x00007FF65B8CEEF3 (0x00000000000001CA 0x0000000000000154 0x0000003ABCD8C4D0 0x0000000000000154)
0x00007FF65B59C379 (0x0000003ABCD8C508 0x0000003ABCD8C5E0 0x0000003ABCD8C5D0 0x00007FF65B599465)
0x00007FF65C78CDBE (0x0000019100000000 0x0000000000000000 0x0000003ABCD8D101 0x00000191E1B35810)
0x00007FF65C4493D9 (0x0000003ABCD8D10A 0x0000003ABCD8D2E0 0x0000003ABCD8D0F8 0x00007FF65C70DDF1)
0x00007FF65C74165D (0x00000191E1B7FCD0 0x00007FF659E04600 0x0000003ABCD8D2B0 0x00000191E1C300A0)
0x00007FF65C4484BC (0x00000191E1B73C30 0x00007FF65AA0DC83 0x00000191E1C32D40 0x0000000000000008)
0x00007FF65C447E9C (0x00007FF600000028 0x0000000000000009 0x00007FF65D3554F9 0x0000000100000009)
0x00007FF65C446A31 (0x00000191E1C3B780 0x00008A62DA3A2FDB 0x00000191E1C3B780 0x00000191E1C3B780)
0x00007FF65C44498B (0x0000003ABCD8DA18 0x0000003ABCD8DA08 0x0000003ABCD8DA08 0x00007FF659DF696A)
0x00007FF65BA4C11E (0x00007FF65D400800 0x00008A62DA3A2DDB 0x2D646E756F72522D 0x3163632D70697274)
0x00007FF65AADA092 (0x00000191E1AF5D30 0x00000191E1AF7C30 0x00000191E1B65B60 0x00007FF659E881A9)
0x00007FF659DF896D (0x00000191E1AF8840 0x00000191E1B65B60 0x00000191E1B669F0 0x00000191E1B356F0)
0x00007FF659E888BE (0x00000191E1B1DC90 0x0000003ABCD8DE50 0x00000191E1B35FD0 0x00007FFDF50000F5)
0x00007FF659827B8A (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0x00007FF659824A2F (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0x00007FF659824832 (0x0000000000000000 0x00007FF65CA97859 0x0000000000000000 0x0000000000000000)
0x00007FF65CA977E0 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0x00007FFD64947BD4 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), BaseThreadInitThunk() + 0x14 byt
es(s)
0x00007FFD6590CED1 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), RtlUserThreadStart() + 0x21 byte
s(s)
clang++: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 14.0.0 (https://github.com/llvm/llvm-project abdb82b)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Dev\LLVM\bin
clang++: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang++: note: diagnostic msg: C:\Users\IVAN\AppData\Local\Temp\ice-f711d4.cpp
clang++: note: diagnostic msg: C:\Users\IVAN\AppData\Local\Temp\ice-f711d4.sh
clang++: note: diagnostic msg:
=== notes
If I replace pop_front(list_t<char, char>{}) by list_t{} directly, it works as expected.
The text was updated successfully, but these errors were encountered: