r263740 - Revert "For MS ABI, emit dllexport friend functions defined inline in class"
Stephan Bergmann via cfe-commits
cfe-commits at lists.llvm.org
Thu Mar 24 01:26:22 PDT 2016
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?
More information about the cfe-commits
mailing list