Report some UnexposedExpr with the adequate name in libclang

Hello !

I'm feeling a bit intimidated to make a request on such a large project, not be sure where to ask, please redirect me if I'm wrong.

I'm using the the C API of libclang, and parsing C code for static analysis purpose by reading the AST, and I must say that the data I get is top notch, very easy to play with :)
FWIW : `clang -v` give me "Debian clang version 19.1.7 (3+b1)"

However, I'm getting here and there some UnexposedExpr, and even if I could likely work around those by hardcoding some "guesses", it would be very good to have the actual data. Moreover I understand that the inner parser of clang does know that already.

I've looked around in the git issue history, but didn't found my answer (even I found other, but that for the end of this post)

The main thing I got is about DesignatedInitExpr, when I write
`struct S s = {.x=0, .y=1}` I get the correct InitListExpr, with two children being UnexposedExpr (each with another getting MemberRef, which is correct)
Note that if I use `struct S s = {0, 1}` I get also an InitListExpr, but the children are IntegerLiteral.
Would it be possible to upgrade UnexposedExpr to something like DesignatedInitExpr ?
I do get the reasoning about API stability, and I didn't fully dove into the inner working of libclang, so maybe some reason (historical, normative... ) restrict that.
Do you want some actual code to test on your end ? If so in which way, I can provide sample libclang code and the code under to test ? I've tried to build a [godbolt example](https://godbolt.org/z/EGoWWW4x7), but the AST I get does not reflect this behaviour, even with my version, I guess that because it use internal AST, and not the one produced by the libclang itself ?

I got that also UnexposedExpr when performing implicit cast for instance `unsigned int a = 42` give me DeclStmt -> VarDecl -> UnexposedExpr -> IntegerLiteral
Again for this pattern I do work my way around (it's actually rather easy, but I feel that it could bit me later on more complex construct...)

There is another example of that, which is about sizeof(), and for which I found a issue, which have been closed, but the issue seems to remains on my end : https://github.com/llvm/llvm-project/issues/15373

Also, even if I don't need C++ immediately, a feature that I would like to see is https://github.com/llvm/llvm-project/issues/22557, which seems to be stale ?

Thanks for any reply, I will perfectly understand that is not on the table, but if some of it could be done, that would help my work going forward

Start with the libclang C API behavior for UnexposedExpr, comparing the DesignatedInitExpr, implicit-cast, and sizeof() examples described in the issue. Review issues 15373 and 22557 for related context, then determine whether exposing more specific names can be specified without breaking API stability; done would require an agreed design and corresponding coverage for these cases.

Written by the indexing model from the issue text.