rsmith added a comment.
Looks fine to me.
Repository:
rC Clang
https://reviews.llvm.org/D42768
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
compnerd updated this revision to Diff 133087.
compnerd added a comment.
address design changes
Repository:
rC Clang
https://reviews.llvm.org/D42768
Files:
lib/AST/MicrosoftMangle.cpp
test/CodeGenCXX/msabi-swiftcall-cc.cpp
Index: test/CodeGenCXX/msabi-swiftcall-cc.cpp
rsmith added a comment.
The Itanium C++ ABI specifies a convention of using the source-level syntax in
the mangling of vendor extensions. This gives a fairly natural naming
convention for such extensions. That would suggest that the identifier to use
here is `__swiftcall__`, not `__swift_cc` /
compnerd added inline comments.
Comment at: lib/AST/MicrosoftMangle.cpp:1717
+Out << '8';
+for (const char *NS : {"__swift_cc", "__Swift"})
+ mangleSourceName(NS);
erichkeane wrote:
> compnerd wrote:
> > erichkeane wrote:
> > > rsmith
erichkeane added inline comments.
Comment at: lib/AST/MicrosoftMangle.cpp:1717
+Out << '8';
+for (const char *NS : {"__swift_cc", "__Swift"})
+ mangleSourceName(NS);
compnerd wrote:
> erichkeane wrote:
> > rsmith wrote:
> > > erichkeane
compnerd added inline comments.
Comment at: lib/AST/MicrosoftMangle.cpp:1061
+if (Ty->getAs()->getCallConv() == CC_Swift)
+ for (const char *NS : {"__swift_cc", "__Swift"})
+mangleSourceName(NS);
rsmith wrote:
> Do we really need both of these
erichkeane added inline comments.
Comment at: lib/AST/MicrosoftMangle.cpp:1717
+Out << '8';
+for (const char *NS : {"__swift_cc", "__Swift"})
+ mangleSourceName(NS);
rsmith wrote:
> erichkeane wrote:
> > When I implemented regcall, it
rsmith added inline comments.
Comment at: lib/AST/MicrosoftMangle.cpp:1061
+if (Ty->getAs()->getCallConv() == CC_Swift)
+ for (const char *NS : {"__swift_cc", "__Swift"})
+mangleSourceName(NS);
Do we really need both of these qualifiers? This
erichkeane added inline comments.
Comment at: lib/AST/MicrosoftMangle.cpp:1717
+Out << '8';
+for (const char *NS : {"__swift_cc", "__Swift"})
+ mangleSourceName(NS);
When I implemented regcall, it was brought up that this was likely a
compnerd added a comment.
@rnk thats not a bad idea. However, I had implemented it slightly differently.
I mangled it as if it was a PMF: so you get `__Swift::__swift_cc::*` as the
type.
Repository:
rC Clang
https://reviews.llvm.org/D42768
compnerd updated this revision to Diff 132528.
compnerd added a comment.
Handle the non-top-level decl case
Repository:
rC Clang
https://reviews.llvm.org/D42768
Files:
lib/AST/MicrosoftMangle.cpp
test/CodeGenCXX/msabi-swiftcall-cc.cpp
Index: test/CodeGenCXX/msabi-swiftcall-cc.cpp
rnk added a comment.
In https://reviews.llvm.org/D42768#994458, @rjmccall wrote:
> No, I mean things like `void foo(__attribute__((swiftcall)) void
> (*fnptr)());`.
Yeah, this was the example I was going to bring up. There's no function
parameter declaration to put the NNS on.
So, here's an
rjmccall added a comment.
No, I mean things like `void foo(__attribute__((swiftcall)) void (*fnptr)());`.
Repository:
rC Clang
https://reviews.llvm.org/D42768
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
compnerd updated this revision to Diff 132328.
compnerd added a comment.
Add test case for non-anonymous non-__Swift::__swift_cc namespace.
Repository:
rC Clang
https://reviews.llvm.org/D42768
Files:
lib/AST/MicrosoftMangle.cpp
test/CodeGenCXX/msabi-swiftcall-cc.cpp
Index:
compnerd updated this revision to Diff 132325.
compnerd added a comment.
Handle namespaces properly
Repository:
rC Clang
https://reviews.llvm.org/D42768
Files:
lib/AST/MicrosoftMangle.cpp
test/CodeGenCXX/msabi-swiftcall-cc.cpp
Index: test/CodeGenCXX/msabi-swiftcall-cc.cpp
compnerd added a comment.
Ah, yeah, I'm just filling in the test cases for those two cases.
Repository:
rC Clang
https://reviews.llvm.org/D42768
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
smeenai added a comment.
Some cases that drop the additional namespacing entirely, which is I think what
@rjmccall was pointing out:
// mangles to ?f@n@@YAXXZ
namespace n {
void __attribute__((__swiftcall__)) f(void) {}
};
// mangles to ?f@s@@QEAAXXZ
struct
compnerd added a comment.
@rjmccall I think both of those are concerns. I'm just putting this up so that
others can grab and test it. It also coincides with the approach that we have
taken elsewhere in clang using the `__clang` namespace for extending the
decoration. What is the case that I
compnerd updated this revision to Diff 132324.
compnerd added a comment.
Handle pointers as well
Repository:
rC Clang
https://reviews.llvm.org/D42768
Files:
lib/AST/MicrosoftMangle.cpp
test/CodeGenCXX/msabi-swiftcall-cc.cpp
Index: test/CodeGenCXX/msabi-swiftcall-cc.cpp
rjmccall added a comment.
Is demangling "correctly" really a more important goal here than not spuriously
failing when presented with a swiftcall function type in a non-top-level
position? I don't know that there was anything wrong with the previous patch's
approach to this if we're just
compnerd updated this revision to Diff 132315.
compnerd added a comment.
Use reserved namespace.
Repository:
rC Clang
https://reviews.llvm.org/D42768
Files:
lib/AST/MicrosoftMangle.cpp
test/CodeGenCXX/msabi-swiftcall-cc.cpp
Index: test/CodeGenCXX/msabi-swiftcall-cc.cpp
compnerd created this revision.
compnerd added a reviewer: rnk.
compnerd added a subscriber: troughton.
Since we are unable to mangle the SwiftCC CC in the function type,
provide an additional namespace qualifier to the decorated source
of `__swift_cc` which serves as the CC identifier. This is
22 matches
Mail list logo
