[lldb][test] Add test for completing ObjCObjectType

[Michael137]

This is a minimal reproducer for a crash where we would try to call DumpTypeDescription on an incomplete type. This crash surfaced as part of an NFC refactor of some of the logic in GetCompleteQualType:

(lldb) expr -l objc -- *(id)0x1234
Stack dump:
0.      Program arguments: ./bin/lldb a.out -o "b main" -o run -o "expr -l objc -- *(id)0x1234"
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var LLVM_SYMBOLIZER_PATH to point to it):
0  lldb                     0x0000000102ec768c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
1  lldb                     0x0000000102ec6010 llvm::sys::RunSignalHandlers() + 112
2  lldb                     0x0000000102ec7fa8 SignalHandler(int) + 292
3  libsystem_platform.dylib 0x000000018c7a8c44 _sigtramp + 56
4  LLDB                     0x0000000116b2030c lldb_private::TypeSystemClang::DumpTypeDescription(void*, lldb_private::Stream&, lldb::DescriptionLevel, lldb_private::ExecutionContextScope*) + 588
5  LLDB                     0x00000001166b5124 lldb_private::CompilerType::DumpTypeDescription(lldb_private::Stream*, lldb::DescriptionLevel, lldb_private::ExecutionContextScope*) const + 228
6  LLDB                     0x0000000116d4f08c IRForTarget::CreateResultVariable(llvm::Function&) + 2076

rdar://129633122

[llvmbot]

@llvm/pr-subscribers-lldb

Author: Michael Buch (Michael137)

Changes

This is a minimal reproducer for a crash reported internally where we would try to call DumpTypeDescription on an incomplete type. This crash surfaced as part of an NFC refactor of some of the logic in GetCompleteQualType:

(lldb) expr -l objc -- *(id)0x1234
Stack dump:
0.      Program arguments: ./bin/lldb a.out -o "b main" -o run -o "expr -l objc -- *(id)0x1234"
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var LLVM_SYMBOLIZER_PATH to point to it):
0  lldb                     0x0000000102ec768c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
1  lldb                     0x0000000102ec6010 llvm::sys::RunSignalHandlers() + 112
2  lldb                     0x0000000102ec7fa8 SignalHandler(int) + 292
3  libsystem_platform.dylib 0x000000018c7a8c44 _sigtramp + 56
4  LLDB                     0x0000000116b2030c lldb_private::TypeSystemClang::DumpTypeDescription(void*, lldb_private::Stream&, lldb::DescriptionLevel, lldb_private::ExecutionContextScope*) + 588
5  LLDB                     0x00000001166b5124 lldb_private::CompilerType::DumpTypeDescription(lldb_private::Stream*, lldb::DescriptionLevel, lldb_private::ExecutionContextScope*) const + 228
6  LLDB                     0x0000000116d4f08c IRForTarget::CreateResultVariable(llvm::Function&) + 2076

rdar://129633122

---

Full diff: https://github.com/llvm/llvm-project/pull/95405.diff

1 Files Affected:

• (added) lldb/test/Shell/Expr/TestObjCIDCast.cpp (+10)

diff --git a/lldb/test/Shell/Expr/TestObjCIDCast.cpp b/lldb/test/Shell/Expr/TestObjCIDCast.cpp
new file mode 100644
index 0000000000000..011bd943b5967
--- /dev/null
+++ b/lldb/test/Shell/Expr/TestObjCIDCast.cpp
@@ -0,0 +1,10 @@
+// RUN: %clangxx_host %s -g -o %t
+//
+// RUN: %lldb -f %t \
+// RUN:  -o "settings set interpreter.stop-command-source-on-error false" \
+// RUN:  -o "b main" -o run -o "expression --language objc -- *(id)0x1234" -o exit 2>&1 | FileCheck %s
+
+int main() { return 0; }
+
+// CHECK: (lldb) expression --language objc -- *(id)0x1234 
+// CHECK: error: Couldn't apply expression side effects : Couldn't dematerialize a result variable: couldn't read its memory

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[adrian-prantl]

Does this test work on Linux?
Is there another constant that is even less likely to ever be a real pointer?
Would 0x00000001 work?

[Michael137]

done