<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 26, 2015 at 1:39 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Mar 26, 2015 at 1:12 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra">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.</div></blockquote><div><br></div></span><div>Wouldn't that be a bug?</div><div><br></div><div>It certainly looks like a bug -- the lookup table has named decl in it for the constructor name that is a wild pointer.</div></blockquote></div><br>Just to relay on the mailing list, I chatted with Richard and he explained that these decls are in some other lexical context on the redecl chain, and thus correct to find via name lookup but incorrect to merge into this lexical context.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I've implemented the fix of special casing the current context's implicit constructor name (should it exist) since those can come from other contexts in the redecl chain and those are the only constructor or conversion function names which can come from other contexts in the redecl chain due to the ODR.</div></div>