troughton marked an inline comment as done.
troughton added a comment.

> Which, I think is just adding something wacky like `@swiftcc@__Swift@@` which 
> would demangle as `__Swift::swiftcc` if the demangler expected an NNS there. 
> Of course, it doesn't, so it won't demangle, but at least you can overload 
> between cdecl and swiftcc then.

Could we do a combination of these? Use the `A` prefix for the CC slot but then 
append the `@swiftcc@__Swift@@` at the end of the qualified name? That way you 
could still distinguish a SwiftCC function and have it correctly demangle with 
existing tools.

As for emitting a proper diagnostic: we definitely can do something better 
here. I wasn't sure what to base it off so went with the simplest option, but 
given that `CodeGenModule::ErrorUnsupported` example I'll take a look and try 
to implement something similar.



================
Comment at: lib/AST/MicrosoftMangle.cpp:2133
+      llvm::errs() << "Unsupported CC for mangling: " << CC << ".\n";
     case CC_Win64:
     case CC_X86_64SysV:
----------------
smeenai wrote:
> You still need the default label, right?
Oops, yes. Thanks. I've added it back.


Repository:
  rC Clang

https://reviews.llvm.org/D40929



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
  • [PATCH] D40929: Unblock Sw... Reid Kleckner via Phabricator via cfe-commits
    • [PATCH] D40929: Unblo... Thomas Roughton via Phabricator via cfe-commits

Reply via email to