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

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

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 :slight_smile:

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.

Here is a patch that adds the field names.

Thanks,
-Brad

0001-Populate-field-names-on-builtin-struct-underlying-__.patch (1.79 KB)

I’m really sorry I totally forgot about this! Thanks for the patch. Committed as r261887

Great, thanks!

-Brad

Great. Thanks to all. The names are now present.

Michka