r189494 - PR16995: Failing to associate static members with their enclosing class

[Eric Christopher]

On Wed, Aug 28, 2013 at 2:00 PM, David Blaikie <dblaikie at gmail.com> wrote:
> On Wed, Aug 28, 2013 at 1:32 PM, Eric Christopher <echristo at gmail.com> wrote:
>>>> That's... tricky. Could you add this in a comment?
>>>
>>> It's partially commented already ("Reuse the existing member function
>>> declaration if it exists" - I could clarify how it could already
>>> exist). Added some other comments in r189504.
>>>
>>
>> Thanks. Otherwise I could easily see us hoisting the check outside of
>> the loop one day. I.e. comments as to why this has to be _right there_
>> are useful :)
>
> Hopefully r189516 covers that.
>

Looks good. Thanks!

-eric

>>>> Also trying to figure out how we're emitting the implicit member without emitting the
>>>> rest of the type.
>>>
>>> Vtables man, vtables.
>>>
>>> If we have a dynamic type, say, with a key function - then we try not
>>> to emit the debug info definition of the type in any TU except the one
>>> that emits the vtable. But if that type has implicit members (implicit
>>> 5 (default ctor, copy ctor, move ctor, copy assign, move assign,
>>> dtor)) we can't be guaranteed they'll be used/declared/defined in the
>>> TU that defines the vtable - so we attach those members to the
>>> declaration. GCC does the same thing. Yeah, it's weird.
>>>
>>
>> Gah.
>
> Yup.