[Patch] Mangle C __stdcall and __fastcall in clang

[Reid Kleckner]

On Tue, Oct 15, 2013 at 3:00 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> > Almost right.  Don't try to mangle non-extern C C++ symbols, as in things
> > that return true for shouldMangleCXXName().  This test case gives the
> symbol
> > ?foo at Foo@@QAGXXZ, which demangles to (public: void __stdcall
> > Foo::foo(void)), which already includes the calling convention anyway.
> >
> > struct Foo {
> >   void __stdcall foo();
> > };
> > void Foo::foo() {}
> >
> > Feel free to commit with that fixed.
>
> The code was already handling that, but looking at it I found that it
> would get confused with corner cases like
>
> extern "C" void __stdcall operator++(Foo &x).
>
> To be fair, it look like gcc and cl get confused too. I have update
> the patch. Would you mind one final review? Thanks.
>

+  const ASTContext &ASTContext = getASTContext();
+  StdOrFastCC CC = getStdOrFastCallMangling(ASTContext, D);
+  bool MCXX = shouldMangleCXXName(D);
+  const TargetInfo &TI = Context.getTargetInfo();
+  if (CC == SOF_OTHER || (MCXX && TI.getCXXABI() ==
TargetCXXABI::Microsoft)) {
+    mangleCXXName(D, Out);
+    return;
+  }

Oh, I see, mingw does the opposite.  :(  I was hoping it would be the same,
but I guess it makes sense because we don't mangle calling conventions
under Itanium.  We might want actually want to add a mangling, seeing as
you can overload based on CC in clang.

I think John would tell you to sink this logic into the MangleContext
subclasses.

+  // Variadic functions do not receive @0 suffix.
+  const FunctionDecl *FD = cast<FunctionDecl>(D);
+  const FunctionType *FT = FD->getType()->castAs<FunctionType>();
+  const FunctionProtoType *Proto = dyn_cast<FunctionProtoType>(FT);
+  if (Proto && Proto->isVariadic())
+    return;
+  if (!Proto) {
+    Out << '0';
+    return;
+  }

Can this be tested?  I thought we removed fastcall and cdecl from variadic
functions, and I have no idea what happens for K&R functions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131015/1651ef67/attachment.html>