llvm dev - Feb 2016 - Question about __NSConstantString and __NSConstantString_tag

Hi

I am the maintainer of pygccxml, which uses clang/llvm and CastXML to parse c++
code.
A user reported a problem with the current llvm 3.9 trunk version (I tested with
r261262).

Our problem is that the AST contains some declarations which were not there
before.

Using "clang -Xclang -ast-dump” on a c++ file, I get the following result:

TranslationUnitDecl 0x8e41ab0 <<invalid sloc>> <invalid sloc>
|-TypedefDecl 0x8e41fe8 <<invalid sloc>> <invalid sloc>
implicit __int128_t '__int128'
| `-BuiltinType 0x8e41d00 '__int128'
|-TypedefDecl 0x8e42048 <<invalid sloc>> <invalid sloc>
implicit __uint128_t 'unsigned __int128'
| `-BuiltinType 0x8e41d20 'unsigned __int128'
|-TypedefDecl 0x8e42378 <<invalid sloc>> <invalid sloc>
implicit __NSConstantString 'struct __NSConstantString_tag'
| `-RecordType 0x8e42130 'struct __NSConstantString_tag'
|   `-CXXRecord 0x8e42098 '__NSConstantString_tag'
|-TypedefDecl 0x8e42408 <<invalid sloc>> <invalid sloc>
implicit __builtin_ms_va_list 'char *'
| `-PointerType 0x8e423d0 'char *'
|   `-BuiltinType 0x8e41b40 'char'
|-TypedefDecl 0x8e42728 <<invalid sloc>> <invalid sloc>
implicit __builtin_va_list 'struct __va_list_tag [1]'
| `-ConstantArrayType 0x8e426d0 'struct __va_list_tag [1]' 1 
|   `-RecordType 0x8e424f0 'struct __va_list_tag'
|     `-CXXRecord 0x8e42458 '__va_list_tag'
`-NamespaceDecl 0x8e42778 <example.hpp:5:1, line:7:1> line:5:11 ns
  `-VarDecl 0x8e8f970 <line:6:5, col:13> col:9 a 'int' cinit
    `-IntegerLiteral 0x8e8f9d0 <col:13> 'int' 1

My file was just containing a namespace (called ns), and an int declaration (int
a = 1).

__NSConstantString and __NSConstantString_tag are now exposed.

I am not sure if this is the wanted behaviour ? We found out that there seem to
have been some back and forth
in the code modifying these structures: r259624, r259715, r259721, r25973.

Maybe someone could enlighten us about this change.
If it’s not a bug, we would like to know more about these structures.

Thanks

Michka

On 02/18/2016 05:51 PM, Michka Popoff wrote:
> Our problem is that the AST contains some declarations which were not there
before.
[snip]
> __NSConstantString and __NSConstantString_tag are now exposed.
[snip]
> Maybe someone could enlighten us about this change.
> If it’s not a bug, we would like to know more about these structures.
To clarify, this is not so much about the appearance of new builtins
but that the structure has fields with no name.  Other builtin
structures like __va_list_tag have names on their fields.  FieldDecl
derives (indirectly) from NamedDecl.

Our concern is that AST processing tools expect to find a name on
fields, and the changes in question introduced fields without names.
Can they be given names, if only for AST consistency?

Thanks,
-Brad

> On Feb 19, 2016, at 7:16 AM, Brad King <brad.king at kitware.com>
wrote:
> 
> On 02/18/2016 05:51 PM, Michka Popoff wrote:
>> Our problem is that the AST contains some declarations which were not
there before.
> [snip]
>> __NSConstantString and __NSConstantString_tag are now exposed.
> [snip]
>> Maybe someone could enlighten us about this change.
>> If it’s not a bug, we would like to know more about these structures.
This struct/typedef are for __builtin___CFStringMakeConstantString (and the NS
variant) and are predefined to make these builtins behave correctly with
modules.  Adding them was intentional :-)
> 
> To clarify, this is not so much about the appearance of new builtins
> but that the structure has fields with no name.  Other builtin
> structures like __va_list_tag have names on their fields.  FieldDecl
> derives (indirectly) from NamedDecl.
> 
> Our concern is that AST processing tools expect to find a name on
> fields, and the changes in question introduced fields without names.
> Can they be given names, if only for AST consistency?
Yes, sounds like a good idea. I’ll take a look at this later today.
> 
> Thanks,
> -Brad
>