r233249 - [Modules] A second attempt at writing out on-disk hash tables for the

[Richard Smith]

On Thu, Mar 26, 2015 at 4:15 AM, Chandler Carruth <chandlerc at gmail.com>
wrote:

> Just FYI in case others see this:
>
> On Wed, Mar 25, 2015 at 8:11 PM, Chandler Carruth <chandlerc at gmail.com>
> wrote:
>
>> +    assert(ConstructorNameSet.empty() && "Failed to find all of the
>> visible "
>> +                                         "constructors by walking all
>> the "
>> +                                         "lexical members of the
>> context.");
>>
>
> I've got at least one case where this assert trips. It seems really
> obscure and only the modules selfhost bot has seen it so I've not reverted,
> but if this is causing anyone trouble, feel free.
>
> I've got it reproduced technically, but still digging into exactly what
> the right fix will be. The case looks like:
>
> (gdb) p ConstructorNameSet.Vector.size()
> $1 = 1
> (gdb) p DC->dumpLookups()
> StoredDeclsMap CXXRecord 0x7fffca58e458 ''
> |-DeclarationName '__count'
> | `-Field 0x7fffc47da8a0 '__count' 'int'
> |-DeclarationName ''
> | |-CXXConstructor 0x7fffca58e8b0 '' 'void (void) noexcept'
> | |-CXXConstructor 0x7fffca58e998 '' 'void (const __mbstate_t &)'
> | `-CXXConstructor 0x7fffca58eb88 '' 'void (__mbstate_t &&) noexcept'
> |-DeclarationName '__value'
> | `-Field 0x7fffc47da900 '__value' 'union (anonymous union at
> /usr/include/wchar.h:85:3)':'union __mbstate_t::(anonymous at
> /usr/include/wchar.h:85:3)'
> |-DeclarationName '~'
> | `-CXXDestructor 0x7fffc47da7b0 '~' 'void (void)'
> `-<undeserialized lookups>
> $2 = void
> (gdb) p clang::Decl::castFromDeclContext(DC)->dump()
> CXXRecordDecl 0x7fffca58e458 </usr/include/wchar.h:82:9, line:94:1>
> line:82:9 in __usr_include.wchar struct definition
> |-CXXRecordDecl 0x7fffc47da950 <line:85:3, line:93:3> line:85:3 in
> __usr_include.wchar union definition
> | |-FieldDecl 0x7fffc47db788 <<built-in>:104:23,
> /usr/include/wchar.h:88:19> col:19 in __usr_include.wchar __wch 'unsigned
> int'
> | `-FieldDecl 0x7fffc47db7e8 <line:92:5, col:18> col:10 in
> __usr_include.wchar __wchb 'char [4]'
> |-FieldDecl 0x7fffc47da8a0 <line:84:3, col:7> col:7 in __usr_include.wchar
> referenced __count 'int'
> |-FieldDecl 0x7fffc47da900 <line:85:3, line:93:5> col:5 in
> __usr_include.wchar referenced __value 'union (anonymous union at
> /usr/include/wchar.h:85:3)':'union __mbstate_t::(anonymous at
> /usr/include/wchar.h:85:3)'
> `-CXXDestructorDecl 0x7fffc47da7b0 <line:82:9> col:9 implicit ~ 'void
> (void)' inline noexcept-unevaluated 0x7fffc47da7b0
> $3 = void
>
>
> And the type in question is roughly:
>
> typedef struct {
>   int __count;
>   union {
>     wint_t __wch;
>     char __wchb[4];
>   } __value;
> } __mbstate_t;
>
>
> So far, naive attempts to produce a more targeted test case have failed.
>

So, the problem seems to be that the class has implicit special members
that are not in the list of lexical declarations of the class but are in
the visible lookup results. In order for this to happen, you might need to
have two definitions of a class that get merged together, where the
implicit special members are only present in the definition that we demoted
to a declaration.

Perhaps the simplest thing to do would be to add the name of the current
class to Names before performing the lexical walk of the class, if it's in
the list of constructor names. That would also let you avoid the lexical
walk entirely if the only constructor or conversion name is for the class's
own constructor(s) (that is, if the class has no inheriting constructors or
conversion functions, but does have constructors, which is likely to be a
very common case).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150326/f4d43cae/attachment.html>