[Lldb-commits] [lldb] 95b5b68 - [lldb][test] Add test for handling conflicting Objective-C NS_OPTIONS typedefs
Michael Buch via lldb-commits
lldb-commits at lists.llvm.org
Tue Jun 10 02:58:38 PDT 2025
Author: Michael Buch
Date: 2025-06-10T10:58:16+01:00
New Revision: 95b5b6801ce4c08e1bc92616321cd4127e7c0957
URL: https://github.com/llvm/llvm-project/commit/95b5b6801ce4c08e1bc92616321cd4127e7c0957
DIFF: https://github.com/llvm/llvm-project/commit/95b5b6801ce4c08e1bc92616321cd4127e7c0957.diff
LOG: [lldb][test] Add test for handling conflicting Objective-C NS_OPTIONS typedefs
Add test that checks whether the expression evaluator can handle
the `NS_ENUM`/`NS_OPTIONS` typedefs from Objective-C `CoreFoundation`.
In the test, `module.h` mimicks the `NS_OPTIONS` typedef from `CoreFoundation`.
The `ClangModulesDeclVendor` currently compiles modules as
C++, so the `MyInt` Clang decl in the module will be a `TypedefType`,
while the DWARF AST parser will produce an `EnumType` (since that's what
the debug-info says). When the `ASTImporter` imports these decls into the
scratch AST, it will fail to re-use one or the other decl because they
aren't structurally equivalent (one is a typedef, the other an enum),
so we end up with two conflicting `MyInt` declarations in the scratch AST
and the expression fails to run due to ambiguity in name lookup.
rdar://151022173
Added:
lldb/test/Shell/Expr/TestObjCxxEnumConflict.test
Modified:
Removed:
################################################################################
diff --git a/lldb/test/Shell/Expr/TestObjCxxEnumConflict.test b/lldb/test/Shell/Expr/TestObjCxxEnumConflict.test
new file mode 100644
index 0000000000000..cf1f2c67e3880
--- /dev/null
+++ b/lldb/test/Shell/Expr/TestObjCxxEnumConflict.test
@@ -0,0 +1,54 @@
+# REQUIRES: system-darwin
+
+# Tests whether the expression evaluator can handle the `NS_ENUM`/`NS_OPTIONS`
+# typedefs from Objective-C `CoreFoundation`.
+# Here `module.h` mimicks the `NS_OPTIONS` typedef from `CoreFoundation`.
+#
+# The `ClangModulesDeclVendor` currently compiles modules as
+# C++, so the `MyInt` Clang decl in the module will be a `TypedefType`,
+# while the DWARF AST parser will produce an `EnumType` (since that's what
+# the debug-info says). When the `ASTImporter` imports these decls into the
+# scratch AST, it will fail to re-use one or the other decl because they
+# aren't structurally equivalent (one is a typedef, the other an enum),
+# so we end up with two conflicting `MyInt` declarations in the scratch AST
+# and the expression fails to run due to ambiguity in name lookup.
+
+# RUN: split-file %s %t
+# RUN: %clang_host -g %t/main.m -fmodules -fcxx-modules -o %t.out
+# RUN: %lldb -x -b -s %t/commands.input %t.out -o exit 2>&1 \
+# RUN: | FileCheck %s
+
+#--- main.m
+
+#import "module.h"
+
+int main() {
+ MyInt i;
+ return i;
+}
+
+#--- module.h
+
+#if (__cplusplus)
+typedef int MyInt;
+enum : MyInt { CASE };
+#else
+typedef enum MyInt : int MyInt;
+enum MyInt : int { CASE };
+#endif
+
+#--- module.modulemap
+module Int {
+ header "module.h"
+}
+
+#--- commands.input
+
+break set -n main
+run
+expression -l objective-c -- (MyInt)5
+
+# CHECK: error: reference to 'MyInt' is ambiguous
+# CHECK: error: reference to 'MyInt' is ambiguous
+# CHECK: note: note: candidate found by name lookup is 'MyInt'
+# CHECK: note: note: candidate found by name lookup is 'MyInt'
More information about the lldb-commits
mailing list