r263740 - Revert "For MS ABI, emit dllexport friend functions defined inline in class"

[Stephan Bergmann via cfe-commits]

On 03/22/2016 06:38 PM, Reid Kleckner wrote:
> Ugh, templates and friend function definitions strike again!
>
> I think this is where "semantic" vs. "lexical" DeclContexts come into
> play. Try doing D->getLexicalDeclContext()->isDependentContext().

Great, thanks, that's what I'd been searching for.

I've put an updated version up for review now at 
<http://reviews.llvm.org/D18430>.

> On Tue, Mar 22, 2016 at 5:23 AM, Stephan Bergmann <sbergman at redhat.com
> <mailto:sbergman at redhat.com>> wrote:
>
>     On 03/17/2016 09:06 PM, Reid Kleckner via cfe-commits wrote:
>
>         Author: rnk
>         Date: Thu Mar 17 15:06:58 2016
>         New Revision: 263740
>
>         URL: http://llvm.org/viewvc/llvm-project?rev=263740&view=rev
>         Log:
>         Revert "For MS ABI, emit dllexport friend functions defined
>         inline in class"
>
>         This reverts commit r263738.
>
>         This appears to cause a failure in
>         CXX/temp/temp.decls/temp.friend/p1.cpp
>
>
>     Ah, indeed, if you stick "-triple %ms_abi_triple" in
>     test/CXX/temp/temp.decls/temp.friend/p1.cpp, it would consistently
>     have failed on all platforms.
>
>     The problem is with friend functions defined inline within class
>     templates (instead of classes), as in
>
>        template<typename> struct S { friend void f() {} };
>
>     But which MSVC apparently wouldn't emit when parsing the class
>     template, anyway, so we shouldn't either.
>
>     So we should filter out friend functions that are defined within
>     class templates:
>
>     (a) either in Parser::ParseLexedMethodDef
>     (lib/Parse/ParseCXXInlineMethods.cpp) before calling
>     ActOnFinishInlineFunctionDef,
>
>     (b) or (probably preferably) later in the "Handle friend functions"
>     block in HandleInlineFunctionDefinition (lib/CodeGen/ModuleBuilder.cpp).
>
>     However, I'm having trouble how to determine that condition, in
>     either case.  For (a), I thought that maybe
>
>        CurTemplateDepthTracker.getDepth() != 0
>
>     could work, but apparently doesn't.  And for (b),
>
>        !D->getDeclContext()->isDependentContext()
>
>     doesn't work, either (as the context of the declaration presumably
>     isn't the class template, but rather the surrounding namespace).
>
>     Any hints?