Closed Gnimuc closed 3 weeks ago
Yes, error recovery is tricky and we need more minimal reproducers to fix things upstream. I do not think we can do anything in that regard in CppInterOp, unfortunately.
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk/usr/include/c++/v1/wchar.h:126:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk/usr/include/wchar.h:89:10: fatal error: 'stdarg.h' file not found
89 | #include <stdarg.h>
| ^~~~~~~~~~
Assertion failed: (Ptr && "dereferencing end() iterator"), function operator*, file /workspace/srcdir/llvm-project/clang/include/clang/AST/DeclBase.h, line 1315.
[75573] signal 6: Abort trap: 6
It turns out this is actually https://github.com/llvm/llvm-project/pull/85378.
I get the following segfault when calling
Declare(code, false)
:The stack trace looks like this:
The reason is that I used the wrong resource-dir, so the interpreter can not find those headers shipped with Clang. But I think it's not good to just crash even if the setup is wrong.
Using
Declare(code, true)
doesn't alleviate the issue because diagnostics are suppressed as well.I also tried to explicitly
llvm::CrashRecoveryContext::Enable()
, but it didn't work.This seems to be a problem in the upstream.
https://github.com/llvm/llvm-project/blob/1bc8b3258e6d42f702fb11eb60d84d0e23935e3e/clang/lib/Interpreter/IncrementalParser.cpp#L255-L283