Previously we were returning "S3_t" for the tag of this struct, because that was the value supplied by libclang -- that is, with llvm-18. With llvm-14, this tag was actually reported as "". Of course, in actuality no tag was provided at all, but the libclang API did not make that very easy to figure out. We now provide getUserSuppliedName, which compares the name as provided by libclang to the actual token in the tree, and if they don't match, we conclude that the user provided no name at all. Perhaps there is a better way to do this, but if so, we can just change the implementation, and keep the contract.
This still leaves the problem that when we traverse the AST for this struct, we see the strict twice: once without the typedef, and then again as a child of the typedef. I don't yet know how to address that; perhaps we should just ignore a struct definition with no tag: after all, such a struct is only useable inside a typedef, and therefore we know that we will see it again. That feels like a reasonable option, but haven't explored that in this PR yet.
Consider
Previously we were returning
"S3_t"
for the tag of this struct, because that was the value supplied bylibclang
-- that is, withllvm-18
. Withllvm-14
, this tag was actually reported as""
. Of course, in actuality no tag was provided at all, but thelibclang
API did not make that very easy to figure out. We now providegetUserSuppliedName
, which compares the name as provided bylibclang
to the actual token in the tree, and if they don't match, we conclude that the user provided no name at all. Perhaps there is a better way to do this, but if so, we can just change the implementation, and keep the contract.This still leaves the problem that when we traverse the AST for this struct, we see the strict twice: once without the
typedef
, and then again as a child of thetypedef
. I don't yet know how to address that; perhaps we should just ignore a struct definition with no tag: after all, such a struct is only useable inside atypedef
, and therefore we know that we will see it again. That feels like a reasonable option, but haven't explored that in this PR yet.