[LLVMbugs] [Bug 10666] definition not emitted for friend operator overload inside instantiated template class

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=10666

Chandler Carruth <chandlerc at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Chandler Carruth <chandlerc at gmail.com> 2011-08-18 04:10:30 CDT ---
(In reply to comment #2)
> FYI, looking at this with nick, I'm struck by the fact that the problem goes
> away if we instantiate Helper outside of a method body. (such as an explicit
> instantiation immediately following the definition).
> 
> It seems that some aspect of template instantiation as it happens during
> delayed method body parsing is responsible for this malfeasance.

This was even more interesting than I originally thought. Here is my further
reduced test case:


template <int N> struct S {
  friend void g1(S s) {}
  void f1() { S<1> s; }
  friend void g2(S s) {}
};
void test(S<1> s1) {
  g1(s1);
  g2(s1);
}


g1's definition is emitted, g2's isn't!!! =D The reason is that we instantiate
the template after processing g1's body, but before processing g2's body. As a
consequence, when we go to instantiate g1 and g2's declarations as part of
instantiating S<1>, we look for function bodies to determine if these function
declarations can be subsequently instantiated more fully. While *if* they have
bodies this is true, not having a body doesn't necessarily mean it isn't true.

There already was a comment indicating it might be useful to preserve this
subsequent instantiation regardless of whether a body is attached, and doing so
avoids this entire problem. Testing doesn't reveal any ill effects when a body
is *not* in fact involved, so all seems well.

I've committed this fix (with accompanying tests) in r137934. If an alternative
implementation would be preferred, please chime in on the review and I'll be
happy to change it up.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.