You're missing the closing curly brace after 0xff

Per http://eel.is/c++draft/dcl.enum#2.sentence-4, underlying type of an enum has to be an integral type, even if grammar allows an elaborated type specifier there. I'm not sure TypeKind.ELABORATED can ever be a correct answer for an underlying type of an enumeration. Could it be that we're looking at a deeper issue here?

CC @AaronBallman @cor3ntin

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.

Hm, this seems to be a regression in Clang 16, not too long ago: https://godbolt.org/z/bEno8Pdhb

I ran the check-clang-python tests using clang 15 - it also does not resolve the enum type to the integer types. But since there was no elaborated type yet, it returns TypeKind.TYPEDEF instead (that matches the godbolt example from above - the TUintType in clang15 - typedef, in clang16 - elaborated and only then typedef).
The test like in patch above (test_enum_values_on_elaborated_type) fails same way as on "main" branch:

    self.assertEqual(ham.enum_value, 255)
AssertionError: -1 != 255

@Endilll , do you think the getIntegerType function on the EnumDecl class should return the true integer type to which any sugared type resolves?

Apologies for the delayed answer, I'm on vacation at the moment.

I asked Corentin and Erich offline, they agreed that having an ElaboratedType node here is surprising, because elaborated type specifiers are not involved. Would it be the correct assessment that this is the core part of your PR? If so, I'd like to hold this off, and resolve an underlying issue instead. You don't have to do it yourself if you don't feel like it. I might get to it myself later.

Does this sound good to you?

Thank you for the analyses. I'm fine with your proposal. I believe, I do not have enough competence to identify the right place where the fix should be applied and I do not want to make blind guesses. So I suppose, this PR can be closed though the issue #108766 will stay open.
Depending on the fix, the enum still may get typedef as underlying type (?, as in clang15) so the fix that provides canonical type on the python code might still be needed. I can provide that if required, ping me on the issue, I can make PR for this.