search for: __nsconstantstring_tag

...128' |-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 *' | `-...

> 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...

On 02/19/2016 10:35 AM, Ben Langmuir wrote: >> On Feb 19, 2016, at 7:16 AM, Brad King wrote: >> [snip] >>> __NSConstantString and __NSConstantString_tag are now exposed. >> 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. >>...

> On Feb 25, 2016, at 7:49 AM, Brad King <brad.king at kitware.com> wrote: > > On 02/19/2016 10:35 AM, Ben Langmuir wrote: >>> On Feb 19, 2016, at 7:16 AM, Brad King wrote: >>> [snip] >>>> __NSConstantString and __NSConstantString_tag are now exposed. >>> 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 Nam...

On 02/25/2016 11:41 AM, Ben Langmuir wrote: > Thanks for the patch. Committed as r261887 Great, thanks! -Brad

Hi, I have implemented a recursive loop to go through all the user of a global variable but I have one issue left. Depending the code, the global variable is using itself: @sSelectedAccount = internal constant %struct.KVObserver { %0* bitcast (%struct.__NSConstantString_tag* @_unnamed_cfstring_.744 to %0*), i8* bitcast (%struct.KVObserver* @sSelectedAccount to i8*), i32 3 }, align 4 With the IR code above, I am stuck in an infinite loop: 1) The global sSelectedAccount has the following user: "i8* bitcast (%struct.KVObserver* @sSelectedAccount to i8*)" 2)...