__NSConstantString and __NSConstantString_tag

[iMichka]

Hi

I got a report from a user that there were some problems with the latest llvm (3.9).
CastXML/pygccxml#32

I just compiled llvm from trunk, and even for an empty c++ file, I get new fields in the xml file that were not there before:

<Typedef id="_4" name="__NSConstantString" type="_10" context="_1" location="f0:0" file="f0" line="0"/>
<Struct id="_10" name="__NSConstantString_tag" context="_1" location="f0:0" file="f0" line="0" members="_14 _15 _16 _17" size="256" align="64"/>

And with this comes a bunch of fields that have no name (I think this is allowed in c++ for structs and unions) and no file (not sure about this one):

<Field id="_14" name="" type="_21" context="_10" access="public" offset="0"/>
<Field id="_15" name="" type="_20" context="_10" access="public" offset="64"/>
<Field id="_16" name="" type="_22" context="_10" access="public" offset="128"/>
<Field id="_17" name="" type="_23" context="_10" access="public" offset="192"/>

I presume that this patch a few days ago introduced these fields:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160201/148942.html

I can rebuild with a version before the patch to double check.

I am not sure on the right behaviour to expect here.

• Maybe these fields are "leaking" in the output (clang -Xclang -ast-dump does display them). If they should stay hidden, we should report this upstream.
• If these fields are valid, we either need to make sure they get a file (maybe file="f0", like other cases we treated before), or I need to teach pygccxml to expect fields without name nor fields (which is getting messy)

I thought you may want to have a look before I ask my question on the llvm mailing list :)

[bradking]

Looking at the Clang commit log I see r259624 that makes a change related to this, r259715 that reverts it, r259721 that re-applies it, and finally r259734 (the one linked above) that makes a fix related to it. This indicates there may have been some uncertainty about how to make the change upstream.

Please raise this on the llvm list. We should either find out they need to fix it, that we need to tolerate it as-is, and/or that there is some way we can distinguish such structures and exclude them from the output (besides memorizing them).

[bradking]

Relevant mailing list thread on llvm-dev is Question about __NSConstantString and __NSConstantString_tag.

[bradking]

The missing field names have been added by upstream LLVM/Clang commit r261887.