[clang] [libclang/python] Fix evaluation of the unsigned enumeration values, #108766 (PR #108769)
Dmitry Fursov via cfe-commits
cfe-commits at lists.llvm.org
Sat Sep 21 08:40:51 PDT 2024
================
@@ -1952,6 +1952,8 @@ def enum_value(self):
underlying_type = self.type
if underlying_type.kind == TypeKind.ENUM:
underlying_type = underlying_type.get_declaration().enum_type
+ if underlying_type.kind == TypeKind.ELABORATED:
----------------
fursov wrote:
My educated guess:
the call chain looks like this: enum_type (cindex.py) -> clang_getEnumDeclIntegerType (clang/tools/libclang/CXType.cpp) -> getIntegerType (clang/include/clang/AST/Decl.h)
Let's use this example:
`using TUintType = uint8_t;
enum class ETUintType : TUintType
{
A = 0xff,
B = 0x20
};
`
>From what I can see, e.g. from ast dumper (clang/lib/AST/TextNodeDumper.cpp, TextNodeDumper::VisitEnumDecl), first it dumps scoped class, then name (ETUintType), then it uses function dumpType() to print the type: first, the one that has been provided by getIntegerType(), but then it is desugared.
EnumDecl 0x5580b1f62490 <line:5:1, line:9:1> line:5:12 class ETUintType 'TUintType':'unsigned char'
This leads me to the conclusion, that getIntegerType() on the AST parser on purpose returns whatever type that enum is defined against without resolving to the target canonical type.
But I would like to hear the opinion from experts.
https://github.com/llvm/llvm-project/pull/108769
More information about the cfe-commits
mailing list